Field note 001 / Systems & operations
Before agents get the keys.
A practical architecture for introducing AI agents to real operations without handing them a shell, production credentials, or unchecked authority.
Authority is not
a convenience feature.
An agent can write a useful plan in seconds. It can also misunderstand a target, repeat a request, operate with stale context, or follow hostile instructions buried in a repository. The moment that agent can restart a production service, publish a site, rotate a credential, or touch customer data, the architecture has to assume that at least one of those things will eventually happen.
That does not mean agents should be kept away from real work. It means the unit of trust cannot be “the agent has access.” The unit of trust must be one bounded, reviewable capability with a known target, immutable input, explicit authority, observable execution, and tested recovery.
Shell access is not orchestration
A chat box beside
a terminal is still a terminal.
The fastest prototype is often a text box wired to a process that can run arbitrary commands. It feels powerful because every operation is technically possible. That is precisely the problem: the system has no enforceable vocabulary for what is allowed.
A prompt such as “deploy the latest version” hides every decision that matters. Which site? Which environment? What commit? Which artifact? Was it built by a trusted workflow? Is another deploy already running? What health check defines success? What happens if the new version starts but returns bad data? Who approved production?
If the server receives prose and decides what command to run, the real permission is still arbitrary command execution.
The safer interface is deliberately less expressive. A request becomes a typed intent such as service.restart, publication.preview, ordeploy.production. Each intent names one registered resource and carries the evidence its policy needs. Anything outside that vocabulary does not run.
Five distinct responsibilities
Read before write.
Proof after action.
Separating these stages makes a failure visible and recoverable. Collapsing them into a single “run” button makes the outcome difficult to explain.
- 01
Observe
Read health, versions, evidence, and current state without changing the target.
- 02
Propose
Describe one typed action against one identified resource and immutable revision.
- 03
Approve
Require the right human authority, risk policy, and fresh step-up authentication.
- 04
Execute
Lease the approved job to an isolated worker with a deadline and narrow capability.
- 05
Verify
Capture the result, health proof, artifact hashes, audit record, and recovery path.
What travels with an operation
Intent needs
an evidence envelope.
Every operational job should be understandable without reconstructing a chat transcript. The durable record needs an idempotency key, the target resource, an immutable revision, the policy version, the requesting actor, any approval, a deadline, bounded retry behavior, and a result.
Idempotency matters because distributed systems repeat themselves. Browsers retry. Workers crash after completing an action but before reporting it. Networks time out. An operator double-clicks. A production deploy or payment refund cannot become two operations simply because one acknowledgement was lost.
A resource mutex matters for a different reason. Two individually valid jobs can be unsafe together. A rollback and a new deployment must not race for the same site. A backup restore must not run beside a schema migration. The queue must understand the resource being changed—not merely the number of available workers.
A disabled button is not a policy
The API must say no
on its own.
Hiding a dangerous action in the interface is useful for clarity, but it is not authorization. A caller can bypass the page. Every protected route must independently verify the session, origin, CSRF protection, current operator authority, approval status, approval expiry, target, risk level, and immutable input.
Higher-risk actions need fresh proof of the human—not merely a session created hours earlier. Publishing, production promotion, DNS changes, secret references, backup restore, and agent capability expansion belong behind step-up authentication and explicit approval.
The approval must also bind to the exact proposal. Approving “deploy this site” and later allowing the artifact to change defeats the review. The approved revision, policy, target, and action become immutable inputs to execution.
Broker capabilities, not secrets
A worker should not
carry the kingdom.
The browser should never receive production credentials. Neither should a general agent workspace. A broker can hold narrowly scoped server-side references and expose only the operations that policy permits. The agent sees a capability and a result—not the underlying token.
Agent workspaces should be disposable, resource-bounded, and unable to mount the host Docker socket or browse operator configuration. Read-only research comes before patch authority. Patch authority comes before preview. Preview comes before staging. Production remains a proposal until a human approves the exact artifact.
For OpenAI-backed work in this system, the provider boundary is subscription authorization through the supported Codex device flow. There is no API-key fallback quietly converting an exhausted or expired subscription into metered usage. If authorization is unhealthy, the job fails closed.
The test is not “did it run?”
Power begins
after rollback works.
An operation is not ready because the happy path succeeded once. Deployment requires a known-good artifact and a health-checked rollback. Authentication requires a second passkey, one-time recovery codes, session revocation, and a drilled recovery path. Backups require an isolated restore. Monitoring requires a stale-data test and an alert path that still works when the monitored server is down.
This changes the development order. Monitoring, audit, approval, and recovery are not polish added after the dashboard looks complete. They are prerequisites for the button. Until those controls pass, the honest interface is a visible lock.
What exists today
No borrowed
readiness claims.
CharlesMorris.org is live as a public, static identity and project record. The private Control applications have a passkey and session foundation, PostgreSQL-backed project registry, append-only audit chain, telemetry path, isolated release process, and fail-closed network design.
Production operations and agent execution remain gated while access recovery, service freshness, external monitoring, approvals, backups, sandboxing, subscription authorization, and rollback evidence are completed. That boundary is a feature: the system reports the authority it actually has.
Operational authority still gatedRelated record