Stop personal data and secrets leaking into LLMs.
Your support agents, your internal copilots, your coding assistants send text to a model all day, and that text carries customer names and card numbers and your own API keys. Swiftward catches it on the way out, redacts it before the prompt leaves your environment, and puts the real values back in the reply, so your own systems never know anything was swapped.
What leaks, and from where
It comes from two directions. The agents your company runs, support, operations, internal assistants, pass customer data into prompts: names, emails, phone numbers, card numbers, national IDs. The coding assistants your developers run paste in secrets: API keys, tokens, private keys, connection strings. Both end up inside a third-party model unless something sits in the way.
What it catches
Dozens of detectors out of the box: the credential types that actually leak, OpenAI, Anthropic, AWS, GitHub, GitLab, Stripe, Slack, Google and Azure keys, private keys, JWTs, plus the common personal data, email, phone, card numbers, passport numbers. Behind those, Presidio for broader name and location detection, and any regular expression or rule you write in the policy DSL for whatever is specific to you. It runs inline, fast enough to sit on every request.
The part that is not commodity
Detecting personal data is something a lot of tools now do. Two things here are not common. It runs on your own infrastructure, so the data never reaches us and redaction happens before the prompt leaves your network. And it is reversible the right way: your data goes to the model as a consistent placeholder, so the model can still reason about it because the same value always reads the same, and on the way back Swiftward restores the real values, so your users and systems get a normal answer and never know the real data stayed home. None of this is hardcoded. What gets masked, in which direction, whether on a prompt to the model or on a result coming back from a tool, and whether the real value is restored afterward or hidden for good, is set by your policy.
A new kind is configuration, not code
When a new kind of sensitive data shows up, you add it as a rule, not a release. Say passports are caught out of the box but a particular national identifier is not: you add it as a new policy version and shadow-test it against live traffic first, which shows exactly which requests the old version was letting through before anything changes for real. No code change, no redeploy, and the change is provable before it goes live.
The same engine underneath
This runs on the same versioned, audited engine as every other Swiftward policy, so each redaction is recorded and replayable like any other decision. Its sibling is code-leak prevention, which keeps your proprietary source code out of a model the same way. Back to AI Governance.