A Secure AI Coding Workflow for Teams
A secure AI coding workflow runs on four stages:
- -Lock down settings and policy before anyone writes a prompt
- -Control what actually gets sent while a developer is working
- -Review and log what happened after the fact
- -Roll all of it out in a way that matches the team's actual size and risk
Each stage on its own covers surprisingly little.
Perfect account settings with no mutation layer behind them still let proprietary code reach a third-party model untouched.
Mutation running with a blank audit trail behind it leaves a team taking its own word for what happened, which rarely satisfies an auditor. Together, the four stages cover most of the exposure a development team is likely to create.
Settings and policy → local mutation → AI tool sees only stand-ins → logging and review
The mutation checkpoint is the one link nothing skips, regardless of which AI tool is in use or which developer is using it.
Before the prompt
Settings
Every account should run on an enterprise or business tier with training on submitted data turned off by default. This is the cheapest fix in the whole workflow, and the one most teams still leave incomplete, since it takes a procurement conversation rather than an engineering sprint.
Confirm retention windows against internal policy, and give someone beyond individual account owners visibility into usage patterns across the team.
Secret checks
Run secret detection before a prompt leaves the machine: the same pattern matching already common in pre-commit hooks, extended to catch API keys, tokens, and credentials headed toward an AI tool instead of a git commit. A minimal version wires straight into whatever hook already runs on save or on commit:
# .pre-commit-config.yaml
repos:
- repo: https://github.com/gitleaks/gitleaks
rev: v8.21.0
hooks:
- id: gitleaks
This catches well-formed secrets reliably: AWS keys, JWTs, anything shaped like a known credential format. It struggles with proprietary business logic or an unstructured customer record sitting in a variable called data, which is exactly the gap the next layer exists to close.
Mutation
A local agent identifies sensitive values in the outbound prompt, credentials, customer data, proprietary code, and swaps each for a realistic stand-in before anything is transmitted. This is substitution, not redaction: the model receives a complete, working prompt and reasons over it normally, and the real values are restored in the response before the developer ever sees the mutated version.
# before mutation, on the developer's machine
patient_ssn = "412-55-0199"
db_pass = "Pr0d!9x2k"
# after mutation, what the model actually receives
patient_ssn = "BETA-4471-XX"
db_pass = "beta_9f21c3"
The model debugs the function, suggests a fix, or explains the logic against fully valid, syntactically correct values. The real ones stay on the developer's machine throughout, on the far side of whatever server that model runs on.
We build this layer at Pretense, disclosed here as one option among several worth evaluating, not the only way to close this gap. It runs locally rather than routing prompts through a vendor's own servers first, and is designed for SOC 2, ISO 27001, and HIPAA workflows, with both certifications currently in progress. Installing it is one command:
curl -s pretense.ai/install | sh
From there, creating an organization and generating an API key connect it to whichever AI tools the team already uses, Copilot, Cursor, Claude Code, or ChatGPT among them.
During
What to send, what to hold back
Even with the controls above in place, it helps to have a simple rule of thumb, and to write it down rather than leave it to judgment in the moment: architecture questions, general debugging help, and code review on non-sensitive logic are fine to send freely.
Anything involving a live customer record, a regulated data field, or a genuine trade secret should route through the mutation layer as the automatic default, ahead of relying on the developer's judgment at 2am during an incident, since judgment is exactly what gives out under pressure.
A team can codify that default in a few lines rather than a memo nobody rereads:
# ai-prompt-policy.yaml
send_freely:
- architecture_questions
- general_debugging
- non_sensitive_code_review
route_through_mutation:
- customer_records
- regulated_data_fields
- trade_secrets
default: route_through_mutation
The default line matters more than any single category above it. Whatever a developer forgets to classify still gets protected.
Review
Some teams add a lightweight human review step for AI-suggested code touching authentication, payments, or data access, treating the suggestion the same way they would treat a pull request from an unfamiliar contributor. The point is consistency: the same review discipline applies regardless of who or what wrote the code. A CI check can flag the paths that matter and leave everything else alone:
# .github/workflows/ai-code-review-gate.yml
on: pull_request
jobs:
flag-sensitive-paths:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Flag sensitive paths for manual review
run: |
if git diff --name-only origin/main... | grep -E '(auth|payments|billing|access-control)/'; then
echo "::warning::This PR touches a sensitive path and needs manual review before merge."
fi
After
Logging for audit
Whatever tool sits in the mutation layer should produce a record of what happened, and leave the sensitive values themselves out of the log entirely. A log line like the one below answers who, what, when, and how many, nothing more:
{
"timestamp": "2026-07-23T14:32:10Z",
"developer": "emily.tran",
"tool": "claude-code",
"repo": "frontend-web",
"file": "src/users/service.py",
"action": "mutated",
"values_mutated": 3,
"types": ["api_key", "customer_id", "internal_hostname"],
"status": "success"
}
This is what turns "we think this is working" into something a security team, or an auditor, can actually verify. It is also the record that matters most in the fifteen minutes after someone asks whether a specific engineer pasted anything sensitive into an AI tool last quarter. IBM's 2025 Cost of a Data Breach Report put the share of AI-breached organizations lacking real access controls at 97 percent. A log like this one is a meaningful part of closing that gap.
Team rollout
Solo dev
Enterprise-tier accounts and a mutation tool running locally cover most of the risk with almost no process overhead:
curl -s pretense.ai/install | sh
Create an organization, generate an API key, and start coding. A single developer can be fully set up in under an hour, most of it spent reading the docs rather than running commands.
Small team
Add a written policy, even a short one, and basic usage visibility so a team lead can spot patterns rather than relying on individual memory. Secret detection at the prompt level is worth adding here, especially for teams that still lack it at the commit level.
Regulated org
Everything above, plus formal audit logging, a defined review gate for code touching regulated systems, and documentation tying each control back to the specific compliance framework it supports, whether that is SOC 2, ISO 27001, or HIPAA. This is also where it is worth confirming vendor compliance claims directly rather than taking a badge at face value, since in progress and achieved mean very different things during an actual audit.
