The Agent Gets Read-Only Credentials: A Trust Ladder for AI in Regulated Systems

The question is no longer whether an LLM agent can query your data warehouse. It can, today, fluently. The question is what happens on the day it's confidently wrong — because in healthcare payments, "confidently wrong" has a dollar sign attached, and sometimes a member's name.

I run AI agents in two very different places: against regulated payment-integrity data at my day job (a Medicare Advantage payer), and against my own Kubernetes platform at home, where the blast radius is my own weekend. Neither environment started from trust. Both started from the same decision, which is the whole thesis of this post: the agent gets read-only credentials, and everything else follows from that.

TL;DR

• Agents earn access on a ladder: human-only → read-only with scoped credentials → draft-producing with human sign-off. Promotion is per agent class, never global.
• Before any class ships, it passes a kill-test: name the failure you're most afraid of, stage it deliberately, and prove the system catches it. If the fear can't be turned into a test, the agent doesn't ship at that tier.
• Guardrails live in infrastructure, not prompts. A database role that cannot write beats a system prompt that promises not to.
• Every root-caused agent failure becomes an automated gate — the same discipline as pre-send file validation, pointed at model output.
• The scarce skill isn't prompting. It's supervision: reading confident output the way you read a confident pull request from someone you don't know yet.

Context: two environments, one discipline

At work, the domain is payment integrity — X12 835/837 file exchange with vendors, reconciliation, and a lot of Snowflake SQL forensics when a balance refuses to explain itself. The agent opportunity is obvious: investigation is read-heavy, pattern-shaped, and endless. The risk is equally obvious: this is regulated data where a fabricated answer can quietly redirect real money decisions.

At home, I run a K3s GPU cluster with GitOps, self-hosted inference, and a Go-based MCP framework (loom-core) that gives agents memory, coordination, quality gates, and sandboxed execution. The homelab is where patterns get proven while the stakes are low. What follows is the discipline that transferred — in both directions.

The trust ladder

Three tiers, promotion earned per agent class:

Tier 0 — human-only. Anything that writes, sends, signs, or pays. No agent touches these paths. Not "an agent with review" — no agent, full stop. The boundary is enforced by credentials that don't exist, not by instructions.

Tier 1 — read-only agents. The workhorses. They hold scoped, infrastructure-enforced read credentials (a warehouse role that physically cannot write; an allowlisted tool surface via MCP) and produce evidence artifacts: the query they ran, the rows that came back, the reasoning that connects them. A human takes any action. The artifact format matters — an agent that shows its queries can be checked in seconds; an agent that shows conclusions must be re-derived to be trusted, which deletes the time savings.

Tier 2 — draft-producing agents. Output enters a human review lane as a draft: a proposed runbook step, a diff, a summary awaiting sign-off. The draft is clearly labeled machine-produced, and the reviewer owns what ships. Nothing at this tier lands on a production surface on its own.

Promotion between tiers is boring and bureaucratic on purpose. An agent class that has run at Tier 1 for months, with its failure modes encoded as gates (more below), can make a case for Tier 2. Nothing skips a rung because a demo went well. Demos always go well.

Kill-tests: prove the guardrail before you need it

Before an agent class ships at any tier, it gets a kill-test. The recipe:

1. Write down, in one sentence, the failure you're most afraid of for this agent. Not the generic fear — the specific one. "It attributes a variance to the wrong vendor and the summary reads as authoritative."
2. Stage that failure deliberately. Seed the wrong data, ask the leading question, hand it the ambiguous case.
3. Verify the system — not the model's good intentions — catches it. The scoped role denies the write and alerts. The output validator rejects the malformed artifact. The abstention path triggers on the ambiguous input instead of an invented answer.

If you can't turn the fear into a test, you don't understand the failure well enough to ship the agent. That's not a process rule; it's a diagnostic. It's chaos engineering pointed at AI, and it has the same virtue: the first time you see the failure, it's on your schedule.

Gates in the pipeline, not the prompt

My team's file-exchange work already runs on a principle that transfers perfectly: every root-caused defect class becomes an automated pre-send gate, so a class of failure gets caught every time instead of once, by whoever happens to remember it. Agent output deserves the same treatment:

• Schema-validated artifacts — an investigation result that doesn't parse doesn't get read by a human, it gets bounced.
• Allowlisted tools — the agent's world is enumerated. New capability is a config change with review, not a model discovering curl.
• Sandboxed execution — anything that runs code runs it in a jail with quotas. In loom-core this is a first-class primitive, and it's the hero image on this post for a reason.
• Diffed scheduled runs — my autonomous agents at home produce output that is diffed against the previous run before anything surfaces. Silent drift is a page, not a surprise.

None of these care how good the model is. That's the point. Model quality is a variable; the pipeline is an invariant.

Supervision is the skill

The failure mode that matters is not the agent that errors — it's the agent that's plausible. Plausible-but-wrong output is optimized to pass a skim, and the defense is a skill I got the old-fashioned way: my first decade in healthcare IT included a lot of debugging an EHR platform's integration layer by reading its Perl from the error message backward. Reading code you didn't write, with appropriate suspicion, until it confesses.

That's exactly the posture supervised AI needs. You read agent output the way you read a confident PR from an engineer you haven't calibrated on yet: check the claims against the artifacts, re-run the load-bearing query, notice what's missing. AI didn't make code-reading obsolete; it made it the bottleneck skill. Teams adopting agents should hire and grade for it explicitly.

What I'd tell a team starting this

1. Permissions are architecture. Decide what agents can never touch, and enforce it with credentials and network boundaries, not vibes.
2. Ship read-only first and stay there longer than feels necessary. Tier 1 evidence-artifact agents are already a large win, and they generate the calibration data you need to justify Tier 2.
3. Kill-test every promotion. Fear → staged failure → verified catch. No test, no ship.
4. Encode every failure as a gate. The second occurrence of a defect class is an engineering failure, not a model failure.
5. Keep humans on every write path until boredom — not excitement — argues otherwise. Excitement is how demos ship; boredom is how systems earn trust.

Honest limitations: this is one team's discipline, months old in the regulated setting, informed by a couple of years of homelab practice, and it stops at Tier 2 today. Human review lanes cost real time, and the trade is deliberate: I'd rather scale slower agents I can defend in an audit than fast ones I have to apologize for.

The pattern held at home before it held at work, and it held at work because none of it was new — validation gates, scoped credentials, observability, and suspicious reading are just integration engineering. The agents are new. The discipline isn't.