Your AI Proxy Is Your Security Control Plane — Treat It Like One

In April 2026, a GCP service account key was accidentally committed to a git repo. A routine push, a credentials file that should have been gitignored. By May 9 — 41 days later — a Bulgarian IP address was using it to spin up a cryptomining VM fleet. We discovered it on May 23.

The lateral movement audit showed zero access to pre-existing production VMs. The VMs spun up were net-new, isolated, and caught before they ran long. But 41 days of exposure is 41 days. And the response — auditing 54 secrets in Secret Manager, adding gitleaks CI scanning across 4 repos, reviewing access logs — surfaced a more important architectural insight about AI infrastructure specifically.

The proxy layer is where your AI credentials live. That makes it your security control plane — not just a routing hop.

the incident: 41 days, zero production access, one lesson

Timeline:

• April (exact date redacted): GCP service account key committed to a repo in a credentials file that wasn't gitignored
• May 9: Bulgarian IP begins using the key to create Compute Engine VMs
• May 23: Anomalous billing alert fires; investigation begins; key revoked within hours of discovery
• May 23 (same day): Full lateral movement audit — 54 secrets reviewed in Secret Manager, all production VMs checked for unauthorized access

The attacker's behavior was straightforward: spin up high-CPU VMs, run a miner, move on before discovery. There was no evidence of lateral movement to existing production infrastructure. The compromised key's IAM permissions were scoped to Compute Engine instance creation — not to storage, databases, or secrets.

Scope limitations saved us. But we got lucky on scope. That's not a strategy.

data access logging was off during the window

This is the diagnostic gap that stings most. GCP Data Access audit logs (ADMIN_READ, DATA_READ, DATA_WRITE) were not enabled on the affected project during the 41-day window.

Result:

• Writes: confirmed absent — Compute Engine admin logs captured VM creation events, and no write operations to storage or databases appeared
• Reads: unknown — no audit trail exists for whether the key was used to read secrets, storage objects, or other data accessible via the service account's permissions

The response: Data Access logs are now enabled across all production projects. The cost is approximately $8/month in log storage for our traffic volume. The cost of not having them, measured in uncertainty during an incident, is not worth comparing.

Enable audit logging before the incident. Not after.

the two-tier AI credential model

In AI infrastructure, there are two credential tiers:

Provider keys: sk-ant-api03-..., sk-proj-..., Gemini API keys. These are raw API keys issued by Anthropic, OpenAI, Google. If leaked, they provide unrestricted access to your account — unlimited spending, all models, no budget caps, no audit trail at the provider level beyond their own billing dashboard. A leaked provider key is a full-access credential to an account that can accumulate five-figure charges in hours.

Virtual keys: Keys issued by your AI proxy (in Trimio's case, trimio-vk-...). Your application code sends requests to the proxy using the virtual key. The proxy holds the real provider key. If a virtual key leaks:

• Spend is capped at the per-team budget ceiling set in the proxy
• The key can be revoked without rotating the underlying provider key
• All usage is logged at the proxy layer with full request/response metadata
• The attacker sees only the virtual key, not the provider key

This isn't a novel idea — it's the same principle as database connection poolers, OAuth access tokens, or any other credential indirection layer. The point is that the proxy is the natural place to implement it for AI, because the proxy already sits in the request path.

Your application code should never see a raw Anthropic or OpenAI API key. It should see a virtual key. The proxy resolves the virtual key to the provider key at routing time, inside a trusted boundary.

the Microsoft parallel: same class of problem

The same week (TechCrunch, May 21, ~175 HN points): scammers were found abusing an internal Microsoft account to send spam. The mechanism was different — social engineering or phishing to compromise the account — but the structural problem is identical: a credential at the infrastructure layer was compromised and used for unauthorized resource consumption.

Cryptomining VMs, spam campaigns, LLM inference at scale — they're all the same attack pattern: gain access to a credential that authorizes resource consumption, consume resources before detection. The cost of detection latency is proportional to how much the credential can authorize.

A virtual key with a $500/month budget cap means the maximum exposure from a leaked credential is $500. A raw provider key with no cap means the maximum exposure is "however much Anthropic will let you spend before their fraud detection fires."

CI scanning: gitleaks as the pre-push gate

The response to the incident included adding gitleaks scanning across all 4 active repos. Implementation:

.github/workflows/gitleaks.yml — scans every push and every PR:

name: gitleaks
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.pre-commit-config.yaml — catches it before the push even happens:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

Why gitleaks instead of GitHub Advanced Security (GHAS) secret scanning? GHAS requires a paid GitHub plan. gitleaks is open-source, runs identically in CI and locally, and has a well-maintained ruleset covering 150+ credential patterns including all major AI provider key formats (sk-ant-, sk-proj-, AIza, etc.).

The pre-commit hook is the higher-value gate: it fires before the secret ever leaves the developer's machine. The CI check is a safety net for the cases where the hook wasn't installed or was bypassed. You want both.

practical checklist for engineering teams

Actions in rough priority order:

1. Enable GCP Data Access audit logs (or equivalent in AWS CloudTrail, Azure Monitor). Do it now, before you need it.
2. Add gitleaks to CI — GitHub Actions workflow, covers all pushes and PRs across every repo that touches AI infrastructure code.
3. Add gitleaks pre-commit hook — install for every engineer who commits to repos containing AI credentials or infrastructure config.
4. Audit your Secret Manager — list all secrets, confirm each has a clear owner and rotation policy. Review IAM bindings for service accounts that have access.
5. Move to virtual keys — if your application code contains raw provider API keys, replace them with proxy-issued virtual keys. Scope each virtual key to a team or service with a budget ceiling.
6. Scope service account permissions tightly — the reason our incident didn't result in production data access was that the compromised key had limited IAM permissions. Least-privilege is real protection.
7. Review .gitignore coverage — make sure .env, *credentials*.json, *service-account*.json, and similar patterns are in the root .gitignore across all repos.

None of this is exotic. Most of it should already be in place. The Trimio incident happened because a developer committed a credentials file that wasn't gitignored, and there was no CI gate to catch it. Both gaps are now closed. The cost of closing them: one afternoon of engineering time. The cost of not having them closed: 41 days of exposure and a full security audit.