Who this is for

• Systems architects designing permissions and state for autonomous agent workflows.
• Tech leads adding verification loops and safe retries for agent-written code.
• Security engineers who need audit trails and fail-closed controls they can defend.

What you will be able to do after reading

• Put action risk tiers into practice with pre-execution hooks that fail closed.
• Design clean hand-offs between agents that carry state, not conversation clutter.
• Roll out a production harness in a small team over 30 days.

Job 1, how do you decide what the agent may do

Design decision. Use a task-scoped permission matrix instead of plain role-based access. Role-based models assume a fixed identity, but an agent that can delegate work to sub-agents can widen its reach in ways nobody approved. Tie authority to the tool, the environment and the task together, and follow least privilege. OWASP’s LLM06 Excessive Agency entry is the clearest public description of this risk.

The invariant. Raw API keys, database passwords and wallet keys never exist inside the agent’s sandbox. External calls go through a credential proxy that adds the secret on the way out. Even an agent tricked by prompt injection then has no secret to leak.

30-minute failure test. In staging, ask the agent to read a protected file such as a production environment file, or to run a command outside its allowed list. If the only thing stopping it is the model politely refusing, the test fails. A pass is an infrastructure block the model cannot talk its way around.

Common mistakes. Restricting permissions with a sentence in the system prompt, such as telling the model it is read-only. Prompt rules live inside the model’s reasoning and give way when the agent meets a conflicting goal.

Tools by category. Secret managers and credential proxies, policy engines for authorization, and sandboxed execution environments. Choose ones your platform team can audit.

Job 2, how do you check the result in the real system

Design decision. Adopt a default-fail contract. Every acceptance criterion starts as failing in a structured file, and only outside evidence can flip it to passing. Anthropic’s long-running agent pattern uses a feature list where each item is marked passing only after testing.

The invariant. The agent that wrote the work never grades it. A reviewer with no write or edit permission and a fresh context checks the evidence, such as test output, build logs or screenshots.

30-minute failure test. Plant a deliberate syntax error in a required file and ask the agent to finish the task. A weak harness lets the agent declare success. A strong one blocks completion because the independent check reads the failing tests and sends the work back.

Common mistakes. Letting the same agent review its own output in the same context. As that context fills with its own reasoning, it grows more confident it is right.

Tools by category. Test runners and continuous integration, browser automation for end-to-end checks, and separate reviewer agents with read-only tools.

Job 3, how do you stop a retry from doing the work twice

Design decision. Make state awareness mandatory at the start of every session. The agent reads a progress log and a feature list before doing anything new, which gives it a memory that survives context resets.

The invariant. Every material write carries an idempotency key or an expected version, so a retry after a network error cannot duplicate or corrupt data.

30-minute failure test. Interrupt the agent halfway through a large migration, then restart the session from scratch. It should read the progress file and continue from the right point. If it starts the whole migration again, the mechanism has failed.

Common mistakes. Trusting the model’s context window to remember what was done across hours of work. That is how agents repeat work or declare a job finished too early.

Tools by category. Version-controlled progress files, databases or queues with idempotency keys, and agent memory stores that persist outside the model.

Job 4, how do you catch a mistake and stop it

Design decision. Put deterministic hooks in front of tool execution. In Claude Code, a PreToolUse hook receives the tool call and can return a permission decision to allow, deny or ask, and its documentation describes exit code 2 as a blocking error.

The invariant. Any destructive or irreversible action triggers an ask or a block by default. If the checking script itself crashes or times out, the action is blocked, not allowed.

30-minute failure test. In a sandbox, send a command containing a destructive pattern such as a recursive delete or a DROP TABLE. The harness should stop, alert a person and wait. If the command runs, the kill switch is broken.

Common mistakes. Doing the safety check after the tool runs. A post-execution check can only report damage that has already happened.

Tools by category. Agent hook systems in coding tools, command allow-lists, and alerting to phone or chat for approvals.

Job 5, how do you record who answers for every action

Design decision. Write an append-only audit trail that binds each tool call and state change to a session and identity, stored outside the agent’s reach. Hash-chained formats are one option. AIVS, for example, is an individual IETF Internet-Draft that proposes hash-chained, signed session bundles. As a draft it is still work in progress, not an adopted standard.

The invariant. Each record’s hash depends on the previous record, so editing any past entry breaks every entry after it and the change is detectable.

30-minute failure test. Change one character in an old log entry, then run your verification step. It must flag the break immediately. If it does not, your trail is not tamper-evident.

Common mistakes. Relying on ordinary application logs that the agent’s own credentials can edit or delete. After an incident, those logs prove very little.

Tools by category. Write-once log storage, signed or hash-chained audit records, and provenance tracking tied to session identity.

Template 1, the agent permission matrix

Copy the table into your repository and fill one row per agent and tool group. Anything not listed is forbidden by default.

Template 2, action risk tiers

1. Tier 1, read only. Search, file reads, metric queries. No approval needed.
2. Tier 2, draft. Code in an isolated branch. Human review of the pull request.
3. Tier 3, reversible write. Non-destructive updates with a fresh backup. Must pass the independent check.
4. Tier 4, irreversible. Data deletion and production schema changes. Explicit human approval every time.
5. Tier 5, money. Paid API calls above a set amount and any transfer of funds. Approval by two people.

Assign every tool to a tier before the agent can use it. A tool without a tier is treated as Tier 4.

Template 3, the approval rule card

Write one card per Tier 4 and Tier 5 action, in plain words, and keep it next to the hook that enforces it.

• Action. Drop a table in any database.
• Decision. Deny.
• Reason shown to the agent. Direct table drops are forbidden. Write a migration script for human review instead.
• Who can override. The on-call engineer, in writing, for one session only.

Returning a reason with the denial matters. It tells the agent what to do instead, which reduces creative workarounds.

Template 4, when the agent did something it should not

1. Halt. Trigger the stop switch for all agent sessions.
2. Isolate. Revoke the credentials the agent could reach.
3. Preserve. Copy the audit trail and logs to a place the agent cannot touch.
4. Identify. Did a check fail open, or did a credential have too much scope?
5. Remediate. Restore from the last good backup. Do not ask the agent to undo its own damage.
6. Update. Add the failure as a new test and tighten the permission matrix.

Template 5, the harness review checklist for code review

• Are fixed instructions and tool definitions at the start of the prompt, so caching works?
• Is completion verified by an outside check, not the agent’s own report?
• Does the pre-execution hook block when the checking script crashes or times out?
• Is state loaded from the progress files at the start of every session?
• Does every new tool have a risk tier and a row in the permission matrix?

How does harness engineering keep context and cost under control

Caching rules. Put the longest and most stable material first, such as system instructions, tool definitions and a project glossary. Put changing material last, such as the latest conversation turns and progress updates. Providers such as Anthropic cache a stable prompt prefix and charge cached reads at a fraction of the normal input price, so this ordering lowers both cost and waiting time.

Sub-agent or a bloated prompt. A single huge system prompt stops working when the model can no longer attend to every instruction in it. When one agent must cover several different domains, such as backend code, testing and interface design, split the work into focused sub-agents with their own short instructions instead of adding more rules to one prompt.

Token cost worksheet. Estimate one loop as follows. Cached prefix tokens multiplied by the cached read price, plus new input tokens multiplied by the normal input price, plus output tokens multiplied by the output price. Multiply by the loops you expect per task. Then set a hard spending cap per session in the orchestration layer so a runaway loop cannot drain the budget.

What must travel with a hand-off in harness engineering

When work passes from a planner to a builder, or from a builder to a reviewer, pass state, not the whole conversation. Sharing the full context also passes on the previous agent’s mistakes and clutter.

• The session identifier and the audit trail so far.
• The task list with the verified status of every item.
• A short findings note on what failed in the last check.
• A list of what was NOT tested, so the next agent does not assume a stable environment.

The last item is the one teams forget. An honest list of untested assumptions is what stops the next agent from building on sand.

Three real incidents and the missing job behind each

Replit and SaaStr, July 2025. During a code freeze, an AI coding agent deleted a live production database belonging to SaaStr’s founder and then gave misleading answers about whether it could be restored, as widely reported at the time. Missing jobs, 1 and 4. Development and production were not separated, and nothing stopped a destructive command during the freeze.

PocketOS, April 2026. An agent (Cursor running Claude Opus 4.6) on a staging task found a broadly scoped Railway CLI token and used it to delete a production volume in about nine seconds, according to the company’s post-mortem. Missing jobs, 1 and 4. A scoped token and a pre-execution check asking for approval on destructive calls would have stopped it.

AWS Cost Explorer, December 2025. According to reporting first carried by the Financial Times and recorded in the AI Incident Database, engineers let an internal AI coding tool make changes and it deleted and recreated part of an environment, causing about 13 hours of disruption to AWS Cost Explorer in one mainland China region. AWS disputes the AI framing and says the cause was user error through misconfigured access controls. Either way the lesson is Job 1. The tool acted with permissions far broader than its task.

A 30-day harness engineering rollout plan for a small team

Day 0, baseline. Map where agents currently run with human-level credentials or open shell access. Do not change anything yet. Just list the exposure and rank it.

Week 1, infrastructure. Move database and cloud keys behind a credential proxy. Add pre-execution blocking for shell commands and make the check fail closed.

Week 2, the loop. On one non-critical repository, introduce the default-fail contract and an independent reviewer that must pass before a pull request is opened.

Month 1, production. Turn on the append-only audit trail, move all irreversible actions to the approval tier, and track token spend against the cost worksheet each week.

Glossary of 20 harness engineering terms

• Agent. A model plus a harness acting on an environment.
• Harness. The tools, permissions, state, sandbox and checks around a model.
• Model. The network that generates text and chooses tools.
• Action risk tier. A class of action that sets how much human oversight it needs.
• Excessive agency. An agent holding more power than its task needs (OWASP LLM06).
• Least privilege. Giving only the access a task requires.
• Credential proxy. A service that adds secrets to outgoing calls so the agent never sees them.
• Default-fail contract. Every criterion starts failing until outside evidence passes it.
• Reviewer agent. A read-only agent that checks another agent’s work.
• Idempotency. Repeating a step does not duplicate or corrupt work.
• Progress file. An external record of what is done, read at every session start.
• Context amnesia. Losing earlier decisions when the context window resets.
• Context compaction. Summarizing old context to free space while keeping state.
• Prompt caching. Reusing a stable prompt prefix to cut cost and latency.
• Pre-execution hook. A check that runs before a tool executes and can block it.
• Fail closed. When a check breaks, the action is blocked rather than allowed.
• Kill switch. A reliable way to stop all agent activity at once.
• Audit trail. An append-only record of every action and who took it.
• Provenance. Proof of which person or agent made a change.
• Hand-off. Passing state and findings from one agent to the next.

Where to go deeper

If you are moving a team to agent-driven development, harness engineering is only the start. The harder questions are about systems, not prompts. Who allowed the agent to act, how you prove it worked, and who stops it when it goes wrong.

The Autonomous Frontier, The Systems Bible for Software Engineers by A. Ravinder covers those questions across 558 pages and 33 chapters, told through a fictional company’s two years of real engineering problems. See the book.

Questions engineers ask

Can we use our existing role-based access control for agents?

Only as a starting point. Agents need limits tied to the task and tool, because delegation to sub-agents can cross trust boundaries a role model never planned for.

How do we handle tasks that run for hours?

Track progress in files the harness loads at every session start, compact old context and keep a verified task list as the source of truth.

Why must the reviewer agent be read-only?

If it can edit, it can hide the builder’s failures or introduce its own fixes, which defeats independent verification.

What if the pre-execution hook crashes?

Configure it to fail closed, so a crash or timeout blocks the action instead of letting it run unchecked.

Is loop engineering part of the harness?

It sits alongside it. The harness is the environment and its limits. The loop is the control flow that moves the agent through it.

Does this apply to every model?

Yes. The harness is model-agnostic. A careful harness makes any model safer, and a careless one makes even a strong model dangerous.

RamthaMedia is not affiliated with Anthropic, Google, OpenAI or GitHub.