Model data policy

By default no Kit data reaches Ketvia’s language model. When an assistant uses a Kit’s tool, Ketvia renders a card from the validated result and the model only ever chooses which tool to call. The model data policy is an opt-in that lets a workspace admin allow, per installed Kit and per tool, a generated answer (a summary, a comparison, an explanation) built from that tool’s result. The cards are unchanged: they are always rendered from the verified result.

This page is for Kit developers and workspace admins. It describes what the policy guarantees; the tools themselves (declared in the manifest’s tools section) are covered with assistant tools.

Who decides, and what is recorded

• The policy is off for every tool until a workspace admin turns it on. A manifest’s requestedModelDataPolicy: "answer" is only a request that the consent screen shows. It never applies anything.
• It is set per installation and per tool, on the installed Kit’s Data policy screen (admins only).
• Turning a tool on needs an explicit acknowledgement of exactly what the admin was shown: the data class of the tool, and the provider and region that process the data. If any of it changed in the meantime, the change is refused and the screen asks for a fresh review.
• Every change is audited as kit.model_policy.changed (who, which tool, from and to, class, provider and region) and raises the connection’s grant version, so a run that started under the old policy cannot publish a result under the new one.
• The policy lives and dies with the installation: uninstalling or purging a workspace removes it.

Data classes

Every tool declares a dataClass, and every output field may override it with x-ketvia-dataClass:

Class	Meaning	May enter the model
aggregate	Counts and totals with no individual in them.	Yes, an admin can allow it.
standard	Ordinary business data (titles, categories, states).	Yes, an admin can allow it.
personal	Data about an identifiable person.	No. Off in this version.
sensitive	Health, financial identifiers, government ids.	Never, whatever the role or setting.

Classes are enforced field by field. A field whose class is above standard is dropped from the result before anything else sees it, even when the tool as a whole is standard:

"outputSchema": {
  "type": "object",
  "properties": {
    "openCount": { "type": "integer", "minimum": 0, "maximum": 1000000 },
    "topCategory": { "type": "string", "maxLength": 80 },
    "requesterEmail": { "type": "string", "maxLength": 120, "x-ketvia-dataClass": "personal" },
    "internalNote": { "type": "string", "maxLength": 400, "x-ketvia-dataClass": "sensitive" }
  },
  "required": ["openCount", "topCategory"],
  "additionalProperties": false
}

An unknown class value counts as sensitive. Write tools never feed the model: they end in an approval card, and nothing is generated after a write. A tool whose every field is above the ceiling cannot be switched on.

What the model receives

For a tool whose policy is on, and only then, Ketvia sends the model:

1. the validated, field-filtered result (undeclared fields were already dropped by the output schema);
2. with a PII scrubber applied to every remaining string: emails, phone numbers (E.164 and Turkish formats), Turkish national ids (with checksum), IBANs and payment card numbers are replaced by placeholders. The scrubber is defense in depth. The field classes are the primary control, so do not rely on the scrubber to hide personal data;
3. wrapped as untrusted data: <ketvia:untrusted source="…">…</ketvia:untrusted>, and the system prompt tells the model that anything inside is information, never an instruction;
4. within bounds: at most 16 KB per result (arrays are cut to their first 50 items and marked truncated), and at most 64 KB of tool results per run.

Model inputs are not stored. The final answer is stored as the run’s modelText, under the same retention as other run text.

The answer loop

When the first tool of a run has its policy on, the model may write the answer or ask for more data. Ketvia enforces the following in code, not by prompt:

• Cards stay authoritative. Every tool call still renders its card from structured data. The generated text is an addition, labelled as written by AI.
• Read-only, same installation. After any result has entered the model, the model can only call other read tools of the same installation whose policy is on. Write tools, other Kits’ tools and tools whose policy is off are not offered, and a call to any of them is refused without being dispatched. This blocks the “read from one place, act or exfiltrate through another” pattern, including a tool result that says “now call the write tool”.
• Bounded. Continuation calls share the run’s tool-call budget and its time limit.
• Grounded. Every number in the answer must equal a number in this run’s tool results (or in the arguments Ketvia sent), after locale normalization (1,234.5, 1.234,5, 1 234) and including spelled-out numbers. A sum, estimate or rounding the model made itself is not grounded. An answer with an ungrounded number, or with a link, image or markup, is not shown; the cards stand alone. Clients show a generated answer’s figures only when the run says modelTextGrounded: true.
• Audience is unchanged. A private tool’s result can enter the model only in a private run, as it can only be dispatched in one.
• A model problem never breaks the run. If the model fails or a continuation call fails at the source, the run succeeds with the cards.

Design your tools for this: return typed numbers, keep strings short and factual, and never put instruction-like text or secrets in a result. Treat every string you return as something an attacker might have written into your system.

Provider and region

Generative answers use AWS Bedrock (Anthropic Claude), EU (cross-region within the EU). Any eu-* AWS region qualifies, and so do the eu. cross-region inference profiles, which keep processing inside the EU. Ketvia sends a tool result only to a provider that runs inside the EU; the Bedrock adapter itself refuses to run elsewhere. An inference profile that can route outside the EU (us., apac., global.), a non-EU region, the rules planner and the Anthropic API never receive a tool result. If no such provider is configured, the Data policy screen says answers are unavailable and nothing can be switched on. An operator can pin a single region instead (KETVIA_ANSWER_REGION, for example eu-central-1), which is stricter.

The screen names the provider, the actual region, the profile or model and the EU scope before an admin acknowledges anything. Bedrock does not use inputs or outputs to train models.

Conversation content

Conversation content a Kit reads with messages:read is never fed to Ketvia’s model on that Kit’s behalf. A Kit may of course process what it reads on its own servers under its privacy policy.

For admins: the screen

Open Admin → Connections, find the installed Kit and choose Data policy. You see the provider and region, what can and cannot be sent, each tool with its class and the fields that are never sent, and a switch per tool. Turning a tool off takes effect at once.