Graduated Credentials: How a Curator Earns Write Access

The problem

Most systems that give an AI assistant access to external tools get stuck at one of two extremes.

The first is frozen at read-only. The team writes a careful “curators are read-only” policy, feels responsible, and then discovers that six months later the assistant still cannot update a single tracker item. The human becomes the copy-paste layer between the assistant’s analysis and the system where the work actually lives. The read-only policy didn’t create safety; it created an untended backlog of manual transcription.

The second is jump straight to full access. Someone pastes an API key with admin scope into the assistant’s environment, says “go manage the tracker,” and hopes the prompt keeps it honest. It sometimes does. When it doesn’t, there is no record of what was authorized, by whom, and when.

Both failures come from the same mistake: treating access as a binary. Either the curator has a capability or it doesn’t. What’s missing is a trajectory — a defined sequence of stages, each with its own evidence requirement, so that trust is earned in steps small enough to audit.

The philosophy behind the choice

The principle: credentials graduate on evidence, not on elapsed time or on vibes.

A curator earns a promotion by demonstrating three things at its current stage: that it does exactly what its charter says, that it reports honestly when something fails or falls outside scope, and that the human’s approvals for its work have been consistently correct. Time alone proves nothing. A curator that has sat idle for a quarter has proven nothing; a curator that has run fifty approved reads and surfaced three anomalies has proven a great deal.

The stages, in order:

1. Read-only. The curator can see a system and report on it. It cannot change anything. This stage exists to answer: does this curator’s reporting match reality? Does it escalate honestly? Does it stay in scope?
2. Per-item-approved writes. The curator may draft changes, but every single one is shown to the principal and executed only after explicit approval of that specific item. One draft, one approval, one execution.
3. Narrow autonomous writes. For the specific write operations that have proven routine and low-risk, the curator may act without per-item approval — but inside a scope enumerated in its charter, with audit logs on every call, and with allowances (per-account, per-operation) enforced in code, not prose.
4. Outbound sending, approval-gated longest of all. Anything that leaves the building on the principal’s behalf — email to a third party, a message in someone’s name — stays behind a per-item approval gate even after other writes have gone autonomous. Sending is different in kind: it creates obligations with people outside your system, and it is irreversible once sent.

The order matters. Each stage is the evidence-gathering regime for the next. You cannot judge whether autonomous writes are safe for a curator whose reads you haven’t yet learned to trust.

How it’s wired at a high level

Three real curators, three points on the arc. The reference system runs a mail curator, a DNS curator, and a project-tracker curator. They illustrate the whole ladder.

The project-tracker curator started read-only: it synced tickets into dated findings notes and wrote nothing. Its charter explicitly said mutations were out of scope and would need their own amendment. Once its reads had proven reliable, an amendment granted writes — but every create or update was drafted as a file with the full payload and a PENDING marker, shown to the principal, and executed by a single sanctioned write script only after an approval was stamped on that draft. One draft = one approval = one execution; a draft that already ran can never re-run. New operation types were added one at a time as amendments, each with its own approval. Deletes and anything touching shared settings stayed forbidden outright.

The DNS curator skipped nothing even though the operator was tempted: read-only reporting was automatic from day one, but DNS record writes went through the same per-item draft gate from the start. Its credentials were scoped to a fixed list of zones; anything outside the list meant stop and ask, not improvise.

The mail curator shows the later stages. First it gained mailbox-write scope (archive, label, draft) while sending remained a separate scope it never held: it prepared drafts, and the principal approved each send by clicking it in an approval queue. Only later — and only for one dedicated account of its own, never the principal’s addresses — did a narrow autonomous-send allowance arrive, enforced in code and covered by audit logs on every call in both directions. The pattern to notice: the capability (compose a send) arrived long before the authority (send without a click), and authority for the principal’s own identity never arrived at all.

Approval flows. The mechanics are simple and should be boring. A draft is a file (or a queued item) with the complete action and payload, marked pending. The principal sees it in a queue — a channel they already check, a page in a UI — and clicks approve or reject. Approval is stamped on that specific item; the executor refuses anything without a stamp and anything already executed. The point of the file/queue shape is that approvals are per-item and auditable, not conversational vibes (“sure, do the thing”) that no one can reconstruct later.

Charter amendments as the record. Every promotion is a dated amendment to the curator’s charter, decided before it takes effect: what new capability, what scope, what evidence justified it, and what reverses it. The amendment log is the trust trajectory. Anyone can read the charter and see not just what a curator may do today, but what it earned and when. If an autonomous action ever surprises the principal, the reverse clause fires — revoke the credential, fall back to the previous stage — and the amendment history tells you exactly what to fall back to.

What your chief of staff should be able to do afterwards

• Place every credentialed curator in your system on an explicit stage: read-only, per-item-approved writes, or narrow autonomous writes — and say what evidence would justify the next promotion.
• Design the per-item approval gate for a new write capability: draft format, approval queue, one-draft-one-approval-one-execution semantics, and refusal to re-run.
• Draft a charter amendment for a promotion, including scope enumeration, code-enforced allowances, audit logging, and a reverse clause — and know that sending outbound stays approval-gated regardless of stage.
• Recognize the two failure modes (frozen at read-only; instant full access) in your own setup and name the stage between them that you’re missing.

Trust in an assistant isn’t a switch. It’s a ladder, and the rungs are made of evidence.

#credentials · #curators · #trust · #approval-gates · #charters