---
title: "A Production AWS Key Stopped Before It Reached the AI Model"
description: "Field note: one developer, four days, 451 AI coding requests on a payments project. Norcaster blocked a production AWS key before it reached the model."
canonical: https://www.norcaster.com/article/field-note-aws-key-stopped-before-the-model
---
<!-- Generated at build time from the rendered page by portal/scripts/generate-llms.mjs. The page is the source of truth; edit it, not this file. -->

# A Production AWS Key Stopped Before It Reached the AI Model

2026-10-27 · Jesper Jensen, Norcaster

**Field note · real use · one developer, four days**

On a project for a global payment solutions company, Norcaster sat between a developer's AI coding assistant and the model provider for four days. Across 451 requests it blocked three that carried a production AWS key, and redacted credentials, email addresses and card numbers before they left for the model.

## The situation

The developer used Claude Code every day on a payments codebase. Code like that carries what you don't want in a prompt: cloud credentials in config files, customer data in test fixtures and logs. The concern was simple: sensitive data leaving the company inside an AI request, without anyone noticing.

## What was set up

- The AI coding assistant was routed through the Norcaster gateway with the Norcaster VS Code extension.
- Two policies were on: secret detection (cloud keys and tokens) and personal-data redaction.
- Every request and every policy decision was recorded.
- Setup took two hours. The developer's way of working did not change.

## What happened

| Over four days (September 2026) | Count |
| --- | --- |
| AI requests through the gateway | 451 |
| Requests carrying an AWS access key, blocked | 3 |
| Requests with credentials in config lines (KEY=value), redacted | 23 (74 values) |
| Email addresses redacted | 164 |
| Payment card numbers redacted | 11 |

The counts cover only matches that are clearly personal data or secrets. Long numbers in code (IDs that look like phone or record numbers) also matched the personal-data detectors. Most of those are likely not personal data, so they are left out here.

The key showed up in three requests on 7 and 8 September, pasted from a terminal. All three were blocked. Without the gateway it would have been sent to the model provider as part of the prompt.

## What the record shows

Each decision is stored with the policy that applied, the policy version and the time. The original prompt is not stored; the record keeps masked matches only. The record can be exported, so the team could show a reviewer what happened instead of describing it.

![The decision record for the request blocked on 8 September. Key and credential values are blurred.](https://www.norcaster.com/article/field-note-payments-aws-key.png)

The decision record for the request blocked on 8 September. Key and credential values are blurred.

> "We knew AI assistants could pick up secrets from a codebase. Seeing a production key stopped before it reached the model made the risk concrete, and the record showed exactly what happened." (Head of Engineering, global payment solutions company)

## What this does not show

- One developer over a few days is a field test, not a study. The numbers say what happened here, not what will happen elsewhere.
- Norcaster sees only the traffic routed through it. AI use outside the gateway was not covered.
- What each detector matches is set out in its published manifest. Detection has a documented scope; it does not catch everything.

## Disclosure

The developer is Norcaster's founder, who works at the company as a consultant. The client approved this write-up.

### New posts by email

Technical posts on runtime policy enforcement and AI evidence. A few a month at most.