Data usage

To answer a prompt, Syntic Code sends context to the Syntic model: your message, the files the agent has read, and the results of tools it has run. For most security reviews this is the central question, so this page lays out plainly what leaves your environment, how it is protected on the way, and how it is treated once it arrives.

What is sent to the model

Only what the agent needs to do the current task travels to api.syntic.ai or your gateway. That means the prompts you write and the specific files and command outputs the agent gathers while working, not your entire repository by default. The agent reads files on demand as a task requires them, so the surface of data that leaves your machine grows with the scope of the work rather than being everything at once. You reduce that surface by scoping tasks narrowly and by using permission and sandbox rules to keep the agent away from paths it should never read.

How it is protected in transit

Traffic between syntic and the model endpoint travels over encrypted HTTPS connections. If you route through an LLM gateway or self-hosted endpoint, you add a controlled boundary where you can inspect, redact, or log requests before they leave your network, which is where many organizations enforce data-loss-prevention rules. Where a proxy performs TLS inspection, ensure its certificate authority is trusted so connections remain encrypted end to end rather than falling back insecurely.

How it is handled and your controls

By default, prompts and responses are processed to serve your request. Your Syntic AI agreement governs how that data may be used, and the model is not trained on your content without the appropriate arrangement. For teams that must guarantee nothing is kept at all, the zero data retention option removes persistence entirely. Combine these platform guarantees with your own controls, scoped tasks, deny rules over sensitive paths, and a gateway that enforces DLP, so data protection is layered rather than resting on a single assumption.