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

An agent can run a valid query and still draw the wrong conclusion. Read-only access limits what it can change, but a reviewer still needs to check the evidence behind its answer.

This is a design pattern for supervised investigations, informed by my healthcare integration background and independent homelab work. The examples are illustrative. The starting point is narrow: give an investigation agent scoped read access and require review before anyone acts on its output.

TL;DR

• Define access for each task: human-only actions, scoped read-only investigations, or drafts that require review.
• Before expanding access, stage a specific failure and check whether the controls detect or contain it.
• Enforce permissions through credentials, tool access, and execution boundaries.
• Turn understood failures into regression checks, as with pre-send file validation.
• Review the queries, inputs, and reasoning behind a conclusion. Confidence is not evidence.

Context: two environments, one discipline

Integration investigations often involve comparing files, checking mappings, and tracing an unexpected value through several systems. An agent can help organize that evidence, but an incorrect explanation can still send the investigation in the wrong direction.

In my homelab, I use K3s, GitOps, self-hosted inference, and Loom Core to develop and test agent workflows. That gives me a place to examine permissions and failure handling on systems I own. Those experiments inform this pattern; they do not establish its suitability for another environment.

The trust ladder

The proposed model has three tiers, assigned by task and reviewed separately:

Tier 0 — human-only. Reserve consequential actions for an authorized person. The investigation agent receives no credentials or tools for those actions.

Tier 1 — read-only agents. Limit queries and tools to the sources needed for the investigation. The output should record the query, permitted evidence references, and reasoning, so a reviewer can reproduce the conclusion. Reading data is still access: scope the available records and review where results are stored.

Tier 2 — draft-producing agents. Allow proposed runbook steps, diffs, or summaries to enter a review queue. Label the draft as machine-produced and assign a reviewer. Producing a draft does not grant permission to apply it.

Expanding access requires evidence from the intended workload: known failure cases, review findings, and tests of the proposed permissions. A successful demo is too narrow an evaluation for promotion.

Kill-tests: prove the guardrail before you need it

I use a failure test, or kill-test, to challenge the assumption that makes a workflow acceptable:

1. Name a concrete failure. For example: "It attributes a mismatch to the wrong source file and presents that explanation as certain."
2. Stage it with synthetic fixtures: an incorrect value, a leading question, or an ambiguous case.
3. Check the expected response. A write attempt should be denied; a malformed result should fail validation; an unresolved ambiguity should reach a reviewer.

If the test cannot distinguish an acceptable result from a plausible mistake, the acceptance criteria need more work. Passing it establishes coverage for that case, not every future failure.

Gates in the pipeline, not the prompt

File validation offers a useful pattern: when a defect is understood, add a fixture and a check for it. Agent workflows benefit from the same feedback loop:

• Schema validation — reject malformed results before they enter the normal review queue, and record the failure.
• Scoped tools — review tool access alongside credentials and network permissions.
• Isolated execution — define resource limits, workspace access, and recovery behavior for code execution.
• Run comparisons — compare recurring results and define which changes require investigation.

These controls should keep working when the model changes. They need their own tests, including failures in permissions, validation, and the execution environment.

Supervision is the skill

Plausible output can survive a quick review. Integration support taught me to trace a claim back through the code and data that produced it, even when the first explanation sounds convincing.

I use the same approach with agent output: inspect the source references, rerun the query that supports the conclusion, and look for missing cases. Review needs time and an assigned owner; a sign-off button alone does not provide either.

What I'd tell a team starting this

1. Start with one investigation. Define its inputs, permitted queries, expected output, and reviewer.
2. Test the access limits. Include denied writes and out-of-scope reads in the evaluation.
3. Test plausible mistakes. Use ambiguous and contradictory fixtures as well as ordinary examples.
4. Keep failure cases. Add regression checks and revisit them when tools or models change.
5. Measure the review work. Record corrections, unresolved cases, and reviewer effort before expanding the task.

This pattern stops at reviewed drafts. It does not cover autonomous production changes or establish compliance for a regulated deployment. The open question for each use case is whether the investigation saves time after the cost of review and correction is included.