Governing Claude Code and LLM agents through technical controls
This series explains how a model is controlled through a harness: the software infrastructure and runtime scaffolding that wraps around a large language model and turns its proposals into actions.
It begins with the overall behaviour of an LLM, which explains why such systems need to be governed. It then introduces the harness, and moves on to the technical controls, such as hooks, permissions and tests, that can be applied to Claude Code to govern its behaviour.
Expressed as a simple formula:
An LLM or AI agent = Model (the brain) + Harness (scaffolding and runtime)
Part 1: How large language models work and what they need to complete a task
What does an LLM need to complete a useful task?
Understand how large language models generate outputs and why useful tasks need relevant context, clear requirements, tools and verification.
Part 2: What an LLM harness is and how it runs tools
How does a model request become an executed action?
Learn what an LLM harness does, how it coordinates model requests and tool execution, and where permissions, isolation and hooks fit.
Part 3: How LLM context, memory and handovers support long-running work
How can work continue when the immediate context changes?
Understand LLM context windows, persistent memory, prompt caching and handovers, with examples of keeping work coherent across sessions.
Part 4: Why LLM agents need governance, permissions and evidence
Who can authorise actions, enforce limits and accept results?
Understand why LLM agents need governance and how purpose, permissions, enforcement, human responsibility and evidence relate.
Part 5: How to govern Claude Code by separating guidance from enforcement
How can instructions be separated from enforceable controls?
How to govern Claude Code by placing every rule that must hold in the enforcement layer: hooks, permission rules, managed settings and protected configuration, with guidance kept short and scoped.
Part 6: How to diagnose Claude Code refusals and test governance hooks
How can a refusal be traced to the layer that made it?
A step-by-step method for telling whether a Claude Code refusal came from the model or from a hook, and for testing that governance hooks allow, refuse and fail as intended.
Part 7: How to classify Claude Code governance incidents and manage the limits of hook controls
What do incidents reveal about the limits of hook-based controls?
How to classify Claude Code governance incidents by the layer that acted, the known limits of hook controls and their compensating controls, a control test matrix and a triage checklist.
Part 8: How to evaluate an LLM governance system
What evidence would support an assessment of outcomes?
How to assess an LLM governance system through accepted outcomes, control decisions, recorded evidence and clearly defined rates.
Glossary
These are working definitions used by the explanatory articles.
| Term | Meaning in this series |
|---|---|
| LLM | A learned language model that processes supplied inputs and generates outputs. |
| Parameters | Numerical values learned during training that support the model's capabilities. |
| Inference | Using a trained model to produce an output from supplied inputs. |
| Token | A unit used to represent text to the model; it need not be a whole word. |
| Context window | The bounded information available to a model interaction. |
| Context engineering | Selecting and maintaining the information supplied as work proceeds. |
| Grounding | Relating an answer or decision to identifiable evidence relevant to the task. |
| Retrieval | Finding and bringing external information into the application's working context. |
| Persistent state | Records retained outside the immediate model interaction for later use. |
| Compaction | Condensing accumulated conversation information to support continuation. |
| Prompt caching | Reusing processing associated with a matching input prefix under the provider's rules. |
| Tool | An interface through which surrounding software retrieves information or performs an operation. |
| Agent | A system that uses model decisions and observations to pursue a task through successive actions. |
| Workflow | A process whose sequence is substantially specified by application code. |
| Operating harness | The surrounding software coordinating context, model calls, tools and execution. |
| Evaluation harness | The system arranging evaluation tasks, capturing execution and assessing outcomes. |
| Guidance | Instructions or explanatory material supplied for the model to act upon. |
| Enforcement | A mechanism that restricts or decides whether an operation proceeds. |
| Permission | Authority for an operation under the applicable task and controls. |
| Isolation | A boundary restricting resources available to an executing process. |
| Hook | A handler invoked by the runtime at a defined event. |
| Skill | Packaged instructions, knowledge or procedures made available through an application. |
| MCP | Model Context Protocol, an interface for connecting applications with contextual resources and tools. |
| Fail closed | Withholding an operation when the relevant control cannot evaluate it. |
| Fail open | Allowing continuation when the relevant control cannot evaluate it. |
| False positive | A control decision that flags or blocks a case which should have been allowed under the intended rule. |
| Provenance | Information identifying the source and history of material or a recorded event. |
| Acceptance criteria | Conditions by which the requested outcome can be assessed. |
| Governance | Arrangements for purpose, authority, responsibility, constraints, evidence and changes. |
Definitions are explained and supported in Parts 1 to 4 and 8; the reference register provides the primary sources used.
Primary reference register
External references were consulted on 18 October 2026. Official documentation is a living source; research findings retain the scope of their original experiments. The sources below support the explanations in this series.
| Reference | Contribution | Source type |
|---|---|---|
| NIST AI 600-1 Generative Artificial Intelligence Profile | Confabulation and the need to assess generated content; section 2.2 | Official voluntary framework companion, July 2024 |
| NIST AI 100-1 AI Risk Management Framework 1.0 | Governance, responsibilities and oversight; GOVERN function | Official voluntary framework, January 2023 |
| How tool use works | Structured model requests and external execution | Anthropic documentation |
| How Claude Code works | Model, tools, context and the operating harness | Anthropic documentation |
| Building effective agents | Workflows, agents and proportionality | Anthropic engineering, 19 December 2024 |
| How the agent loop works | Model and tool exchanges within an agent run | Anthropic documentation |
| Choose a sandbox environment | Permission decisions and isolation boundaries | Anthropic documentation |
| Automate actions with hooks | Event-triggered handlers and different decision mechanisms | Anthropic documentation |
| Effective context engineering for AI agents | Context selection, retrieval and continuity concepts | Anthropic engineering, 29 September 2025 |
| Language Models are Few-Shot Learners | Distinction between contextual examples and parameter updates | Brown et al., original research, 2020 |
| Lost in the Middle | Context capacity versus information use in tested models and tasks | Liu et al., TACL, 2024 |
| Prompt caching | Reuse of input-prefix processing | Anthropic documentation |
| Work with sessions | Conversation persistence and its distinction from filesystem state | Anthropic documentation |
| Effective harnesses for long-running agents | Reported coding experiments concerning continuity and progress | Anthropic engineering, 26 November 2025 |
| Extend Claude Code | Skills, extensions and separate subagent contexts | Anthropic documentation |
| MCP architecture overview | Applications, tools and contextual resources connected through MCP | Official protocol documentation |
| Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection | Indirect prompt injection through retrieved material | Greshake et al., original research, 2023 |
| Demystifying evals for AI agents | Agent and evaluation harnesses; transcript versus outcome | Anthropic engineering, 9 January 2026 |
NIST material supplies governance vocabulary; it is not a certification of any configuration described here. Anthropic material documents its products or reports its own engineering experience. The research papers establish findings within their stated experimental scope.
Vikram Mohan
A London based technology consultant who has a background in cybersecurity, risk, assurance and controls, covering their design, testing and reporting.
Vikram audited the controls of one of Europe's largest banks from within its Economic Crime and Cybersecurity Audit team, including third party risk reviews of its largest cloud and outsourcing partners, and reported to its audit committee. He has more than ten years of consulting, transformation and cybersecurity experience at Capgemini Invent, Deloitte, Accenture and Tata Consultancy Services, across the public sector, financial services and several other industries.
- Frameworks: NIST Cybersecurity Framework, COSO Internal Control, GDPR and DPIA, UK operational resilience (PRA SS1/21, FCA PS21/3), DORA
- BCS Chartered IT Professional (CITP); CISSP in progress
- MBA, SP Jain School of Global Management; MSc Distributed Systems and Networks, University of Kent