Coding with an AI assistant stopped being a novelty. Many of us write code with Claude, ChatGPT, Copilot or Cursor every day, and that added a new channel for information to leave through: every time you paste code into a prompt, that code leaves your machine toward a third-party service. It’s the same kind of leak we saw with logs in part 4, except now you open it yourself by pasting.
This is the security fundamentals series, and this closer covers a topic that wasn’t on this list two years ago.
The right mental model
The rule that simplifies everything: the AI assistant is a third party, whichever one it is. It doesn’t matter how useful it is or how integrated into your editor. The moment a cloud service processes your text, that text has left your control and traveled to infrastructure you don’t run.
That doesn’t mean don’t use AI. It means treating the prompt as what it is: a channel for information to leave your machine. The question before pasting something isn’t “does this help the assistant understand me?”, it’s “do I care if this leaves my computer?”.
What never goes in the prompt
There’s a short list that shouldn’t be pasted into an assistant, cloud-based or not:
- Secrets and credentials. API keys, tokens, passwords, private keys. A secret pasted into a chat is a leaked secret, with the added problem that you no longer control where it gets logged.
- The contents of your
.envor config files with real values. This is the most common slip: you paste a whole file for the AI to review, not noticing it carries the keys inside. - Certificates and provisioning profiles. Your signing certificate and distribution keys are your app’s identity. They have no reason to be in a prompt.
- Real users’ personal data. Emails, names, locations, any production record. If you paste a response JSON to debug it, check that it doesn’t carry a real person’s data.
If a secret ever touched a prompt, treat it as compromised and rotate it, just like if it had touched git history. Deleting the message doesn’t undo that it was already transmitted.
How to share code without leaking
Most of the time you don’t need to paste the secret for the assistant to help you. You need the structure, not the value. Before pasting, redact:
// Instead of this:
let apiKey = "sk_live_9f2a8c...b41"
let baseURL = "https://api.real-client.com"
// Paste this:
let apiKey = "<API_KEY>"
let baseURL = "https://api.example.com"The AI reasons just as well with a placeholder as with the real value, because what it cares about is the shape of the code, not the content of the secret. The same principle applies to data: if you need help with a parser, build a minimal example with made-up data instead of pasting your server’s real response.
When you report an error, be just as careful with what you copy. A stack trace or a log pasted straight in can carry a token or a path with sensitive information, exactly what we saw in part 4. Read it before pasting it.
Know where your data goes
Not every assistant treats your data the same, and the difference matters.
A cloud assistant processes your text on remote servers. What happens afterward depends on the configuration and the plan: enterprise tiers usually offer zero or limited retention and the guarantee that your content isn’t used to train models, while consumer plans may have different policies. Don’t assume it: check each tool’s data-use and retention settings, and turn them on where they apply.
For genuinely sensitive code, there’s the option of sending nothing to the cloud. Local models running with Ollama or LM Studio on your own Apple Silicon Mac process everything on device; nothing leaves your machine. They perform below the large cloud models, but for working on code with strong confidentiality constraints, that gap is offset by the data not traveling.
If you work in a regulated environment or under a confidentiality agreement, this stops being a preference and becomes an obligation: certain code or data may simply not be allowed to leave your infrastructure. Know that line before you paste.
Don’t trust generated code blindly
There’s a second risk, less obvious than the leak: the code the AI hands back can have security problems. An assistant can suggest, perfectly naturally, a hardcoded key, weak crypto, an ATS exception that opens up cleartext traffic, or a database query vulnerable to injection. It doesn’t do it out of malice; it generates what’s most probable, and there’s a lot of insecure code on the internet.
Everything we saw in this series is your checklist for reviewing generated code. If the assistant proposes storing a token, does it go to the Keychain or to UserDefaults? If it builds a network call, does it respect TLS or disable validation “to make it work”? Generated code gets reviewed with the same critical eye as code from any other source, all the more when it touches security.
A concrete and growing case: hallucinated dependencies. Sometimes the AI suggests a package that sounds real but doesn’t exist, or that exists but isn’t the one you think. Before adding a dependency an assistant recommended, verify it’s real, official and maintained. Blindly installing what a prompt suggests is an entry point for malicious code.
Assistants that read your repo
Agentic tools embedded in the editor, like Cursor or assistants that work over the whole project, add a wrinkle: they can send more context than you think. Not just the open file, sometimes fragments of the entire repository. It’s worth knowing which files go into that context and keeping out of its reach what shouldn’t leave, with the same .gitignore discipline you use to not leak secrets to git.
And since these tools also read external content (documentation, issues, dependencies), they inherit the risk that such content carries hidden instructions aimed at the assistant. It isn’t theoretical paranoia: it’s the reason to review what an agent proposes before letting it act on your project, instead of accepting changes automatically.
What we’ve got
- The AI assistant is a third party; pasting something into a prompt is taking it off your machine.
- Never share secrets, credentials, certificates or real users’ data; if a secret touched a prompt, rotate it.
- Share the structure, not the value: redact with placeholders and use made-up data for examples.
- Know where your data goes, turn on zero-retention and no-training where you can, and use local models for confidential work.
- Review generated code with this very series as a checklist, and verify every dependency it suggests.
Closing the fundamentals block
That closes the first line of the series. An iOS dev who has these five topics settled (where to store secrets, how to encrypt files, what to do with API keys, how not to leak through logs, and how to work with AI without opening leaks) already covers most of the security mistakes that show up in a basic audit.
Fundamentals are the floor, not the ceiling. The next lines of the series go into authentication and identity (biometrics, passkeys, token handling), network security (TLS, certificate pinning, App Attest), privacy and compliance (privacy manifests, required reason APIs), and hardening (Secure Enclave, CryptoKit). Each one on the same principle: protect the user without depending on anyone looking.
Sources: Security (Apple) · Ollama · LM Studio