How I handle your data, in engagements and in JAMES
Short version: in an engagement I reach your data through accounts you control, with the least access each task needs, and nothing you share trains a model. Every change an agent proposes waits for human approval and is logged so it can be traced and reversed. JAMES, my product, is hosted in Germany.
Key takeaways
- You can switch off all of my access in one place, because it runs through accounts you create and own.
- AI never acts on your systems without a plan a human has read and approved first.
- JAMES deletes customer data within 30 days of account deletion, and its backups expire within a further 30 days.
In an engagement
- Your accounts, your switch. I work through identities you create in your own systems. Revoking them ends my access everywhere at once.
- Least privilege. Each integration and agent gets the narrowest access its job needs. Where an AI only needs answers, it does not get direct access to the underlying tables.
- Your data rules. Data residency follows your regulation, and the model providers in a build are chosen to fit it.
- No training on your data. Nothing from your systems is used to train a model.
- Guardrails. Agents run with limits on what they may call and how much they may spend, so a bad prompt cannot run up costs or touch what it should not.
What happens when the AI is wrong
Every change follows the same loop, which is the core of Supervised AI Delivery: the agent writes a plan a person can read, a named human approves it, and only then does anything run. Complex or unusual requests go back to that person for confirmation instead of being guessed at. Each executed change is logged with who asked for it and what it touched, so a wrong change is found quickly and reversed.
- Plan
- Approve
- Execute
- Log
For the Auditlab engine this loop is what keeps the audit file traceable: every plain-language question, the query it became and the result are on record.
In JAMES
JAMES, the AI Jira administrator I build, runs on the same principles and is governed by its own Data Processing Agreement. In summary:
- Hosting. JAMES runs, and keeps its data, in Germany.
- Sub-processors. Every outside provider JAMES relies on, the AI model provider included, is named in its published DPA.
- Encryption. Connections use TLS; the database is encrypted at rest; stored Atlassian API tokens are encrypted with AES-256-GCM, or you can use session-only tokens that are never written to the database.
- Approval before change. JAMES changes a Jira site only after an authorized user approves its change plan, and server-side code checks each change against that plan. Deleting objects is possible only on JAMES Premium and needs a second, separate confirmation.
- Your Jira permissions apply. JAMES acts with the permissions of the Atlassian account whose token you supply, and opens issue content only for a task a user requested that depends on it.
- Retention. Customer data is deleted within 30 days of account deletion; backups expire within a further 30 days.
- Incidents. Security incidents are notified within 96 hours.
More detail on the product side is on how JAMES enforces security.
What I do not claim
Viter is not independently audited yet, so there is no SOC 2 or ISO 27001 report to send. What I can send is a DPA, the answers to your security questionnaire, and a call with whoever reviews vendors on your side.
Data processing agreements
A DPA is available for every engagement on request, and JAMES has its own. Ask through the DPA request page or at hello@viter.io.
Questions
Do you use our data to train AI models?
Where is data processed?
Can an agent delete things in our Jira?
If your security review has questions this page does not answer, bring them to the call.