A Secure AI Coding Workflow for Teams

A secure AI coding workflow runs on four stages:

1. -Lock down settings and policy before anyone writes a prompt
2. -Control what actually gets sent while a developer is working
3. -Review and log what happened after the fact
4. -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 an empty 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 every prompt passes through, 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 where you might expect 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 while a prompt is still on 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 as well as toward 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, a different approach from redaction: the model receives a complete, working prompt and reasons over it normally. Code identifiers are swapped back byte-exact in the response, while secrets and PII stay as stand-ins in the answer by design, so a prompt-injected model has only stand-ins to exfiltrate.

# 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 for closing this gap. It runs locally, so prompts go straight from your machine to the AI provider with vendor servers kept out of the path, and it is built to support SOC 2, ISO 27001, and HIPAA programs, 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 so the moment calls for a rule over judgment: 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, which beats a memo that sits unread:

# 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 keep the sensitive values themselves out of the log entirely. A log line like the one below answers who, what, when, and how many, and stops there:

{
  "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 found that 97 percent of AI-breached organizations lacked real access controls. 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 zero 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, with the commands taking only minutes.

Small team

Add a written policy, even a short one, and basic usage visibility so a team lead can spot patterns across the team, beyond what any one person remembers. 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, looking past the badge, since in progress and achieved mean very different things during an actual audit.