Why security isn't a later problem
The most common security mistakes with AI tools don't come from spectacular incidents. They come from everyday carelessness: a screenshot with internal URLs, a log excerpt with tokens, a prompt that contains customer data.
These mistakes happen because security gets treated as a "later" problem — once the workflow runs, then I'll deal with it. That pattern almost always leads to avoidable trouble.
Data leaks: the most common problem
What's often overlooked: whatever you send to an external model goes there. Not necessarily into training data (that depends on the provider and contract), but into processing. That's relevant for regulated industries, customer data, internal systems.
Practical filter rules I apply:
- Check screenshots for sensitive URLs before sharing them
- Truncate logs — the first 50 lines are often enough for diagnosis
- API keys, tokens, credentials never in prompts
- Replace customer-identifiable data (placeholders, anonymization)
Keep tool permissions minimal
An agent that isn't allowed to do anything can't break anything either. Minimal permission per task isn't theory — it's a practical safeguard.
Concretely: read-only wherever possible. Write access limited to specific paths. Deploy and merge actions always with human confirmation. That sounds restrictive, but in practice it's barely an obstacle to real productivity.
Clarify provider data handling
Some providers have clear compliance statements (SOC 2, GDPR data processing agreements), others don't. That's homework per provider that you can't delegate away.
For teams: introduce a short provider-approval process. Not bureaucratic, but clear. Which providers are approved, which need review, which are excluded.
Define action boundaries
Agents that take actions — opening PRs, triggering deploys, sending emails — need clear boundaries. Defined ahead of time, not after an incident.
The questions I settle for every workflow: what may the agent do automatically? What needs my confirmation? What shouldn't it be able to do at all? Put those boundaries in the skill definition, not in your head.
For teams: three simple measures
- Provider list: which are approved, which aren't. Created once, maintained as things change.
- Data classification: internal, confidential, public. A clear rule for which class may go to external models.
- Confirmation protocol: which actions always need human approval. Short list, binding.
It's not a lot of effort. But it's the difference between a team that uses AI safely and one that's waiting for an incident.