# The architecture behind accountable autonomy

> Anyone can put AI to work these days. What lies between “Claude Code installed” and agents running safely is the subject of this essay.

- **Author:** Dominic Asche
- **Date:** 09 / 2026
- **Reading time:** 13 min
- **URL:** https://fse-group.de/en/think-tank/the-architecture-behind-accountable-autonomy

Install Claude Code and ten minutes later you have an assistant that writes code and runs commands. That is the easy part. The hard part begins the moment the model stops merely answering and starts acting.

Anyone can put AI to work these days, but we believe many are not clear about the responsibility that follows from it. What lies, for us, between “Claude Code installed” and agents running safely is the subject of this essay.

Install Claude Code and ten minutes later you have an assistant that writes code, reads files and runs commands. Turn on bypassPermissions, grant access to computer and browser, and “Claude” handles its first tasks on its own. That is impressive, and it is the easy part.

The hard part begins the moment the model stops merely answering and starts acting: creating a ticket, approving an order, preparing a customer reply. Data protection, auditability and more. Now, as a company, you have to be able to say on what basis something was done, which authority applied, what data flowed in the process, on what legal basis it was processed and who made a decision.

We have brought agents into the team as full colleagues: in ticket handling and delivery, in monitoring our systems, in customer processes. What it takes to establish that safely, which mistakes we made along the way and what investment we have built, is what we want to share below. We believe many are not aware of the consequences that arise from using programs like Claude. We at least were not aware of them beforehand.

### What an installed tool can do, and what it cannot know

Claude Code brings a lot with it: permissions per tool, rules for allow, ask and deny, hooks for your own checks, centrally managed settings for companies. Anthropic has created the technical preconditions for controlled operation with that, and we use every one of them. Everyone has to use all of it and, in our view, ensure a great deal more themselves on top.

Are you aware of, or is it transparent to you, which actions Claude or Codex carried out? Could it be that something appeared in an internal reasoning step that was not allowed to become public? In other words, is it prevented that Claude ever ran a bash command against a .env file or a secret? Or sent an email from a business partner to the Anthropic API without a suitable legal basis or the required data protection measures? How was it ensured that the folder contained no document whose processing was not permissible in this context? bypassPermissions sends its regards with “hello IT security incident”, and possibly “hello data protection incident”.

The difference can be shown in a table. On the left what the installation brings with it. On the right what is missing when an agent is to take on responsibility, and how we solved it.

### How does the agent know what applies?

**Claude Code after installation**

From whatever is in the prompt and in the opened files and folders, claude.md, instructions in the skill and/or rules folder

**Enterprise grade at FSE**

Standardised starting prompt with fixed skills, guardrails enforced through our own harness

A necessary LLM wiki as the knowledge base, with source, revision date and a governance process that resolves gaps and contradictions

### What is it technically allowed to do?

**Claude Code after installation**

Whatever the local permission list allows

**Enterprise grade at FSE**

Every message, every call to Claude passes through a central FSE policy gateway that checks for PII, disallowed commands and adherence to the agreed set of tools

### What is allowed to happen in business terms?

**Claude Code after installation**

Technical permission mechanisms exist. Company-specific business limits, however, are unknown to the tool after installation unless we define and technically enforce them ourselves.

**Enterprise grade at FSE**

Guardrails are enforced technically, meaning deterministically through the policy gateway, and procedurally through strict instructions. Tasks are built along this logic with their own rule set:

- if the task needs its own trigger, it becomes an agent
- if it needs its own large reading context, it becomes a subagent
- otherwise it becomes a skill

Agents and skills hold restricted rights through centrally controlled MCP servers, authentication, authorisation and gateway policies, analysed against a risk threat model, a zone assessment and our own access logic along CRUD, the four-eyes principle and general pentesting.

All conversations and actions, meaning agent logs, are stored, examined and, in case of misconduct or disallowed actions, reported immediately, together with follow-up policies

### What happens to personal data?

**Claude Code after installation**

It sits in the context as soon as it is read

**Enterprise grade at FSE**

Masking and checking. Direct identifiers and defined sensitive data classes are removed, masked or tokenised before the model call wherever they are not required for the processing purpose.

This happens by placing the local Claude app, the policy gateway and the Anthropic API in sequence at the transitions defined for it: before the model call, before writing, before storing.

As a matter of principle, organisational measures should prevent personal data from ever appearing in prompts or POSTs where it is not required for the given purpose

### Who decides when something is unclear?

**Claude Code after installation**

The person having the conversation with Claude or Codex

**Enterprise grade at FSE**

A standardised, auditable decision process with fixed rules, documented in a ticket, with escalation paths and only within predefined rules

### How does a change to an agent go live?

**Claude Code after installation**

Change a file, claude.md for instance, and save it

**Enterprise grade at FSE**

Merge request, human approval, regression tests, evals against known failure cases, test cases and assessment

### What does the system learn from a mistake?

**Claude Code after installation**

Nothing organisationally. Claude Code can persist findings across sessions through auto memory or CLAUDE.md. Organisational learning does not follow from that.

**Enterprise grade at FSE**

Continuous analysis of agent runs against evals and KPIs, which then turn into a rule or a technical limit, or change processes

Agents or prompts are given a goal. Depending on the setting, the harness attempts to reach that goal, and with the /goal command the tool keeps working and keeps trying until a separate evaluator judges the defined completion condition to be met. The longer and the more autonomously such a run works, and the more tools and data sources are accessible to it, the larger the attack surface becomes. Sensitive data can enter the model context, and with it reach the external harness provider, if file contents, tool outputs or other local information are fed back unfiltered. Only someone who classifies a harness provider such as OpenAI or Anthropic as a secure zone and secures the specific data flow accordingly can still speak of responsible operation at that point.

### Knowledge with provenance

In a serious corporate context, agents do not work with whatever happens to be in a prompt or was instructed, but with their own versioned knowledge base. It holds company rules, process descriptions and system knowledge, condensed from documentation pages. Every page knows its source and that source’s revision date. So an agent does not just read an answer. It sees where the answer came from and how old it is. Building on the concept of an “LLM wiki” described by [Andrej Karpathy](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), we model authority, value and hierarchy of knowledge. Simply handing a harness unfiltered knowledge from, say, a Confluence or a drive is, as the following example illustrates, utter nonsense:

In agile times documentation is almost by definition n-1. For example: two documents describe the same rule differently. The system does not pick the variant that sounds more plausible, which a model without this safeguard may well do. It flags the conflict on both sides, and a dedicated process puts such cases up for review daily. The clarification runs as a guided process, a human gives the answer, and it is written back into the source, not only into the knowledge base.

![Screenshot from our operations platform, in German: one row of the knowledge base conflict list, tagged with the identifier C-2c5e39 and marked as a rule page. The finding is that rule 25 of the source requires the technical roadmap to be read and approved before the first line of code in a hybrid run, while the implementation command only requires reading and knows no approval step. Next to it sits the affected source, the rules for ticket implementation, with a link, the note that this is a conflict within a single source with no counterpart, and on the right a button to settle the case in Claude.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-brain-conflict.png)

Behind this sits an important distinction: an error in condensing can be corrected against the source. The question of which of two company rules applies from now on is not a correction. It is a decision for the organisation. A system whose sources contradict each other is dangerous as a basis for autonomous processes.

### Instruction is not enforcement

A rule in the context window tells the model what it should do. Whether a specific action then actually happens deterministically has to be secured elsewhere. The context window is no guarantee that a rule is enforced. This behaviour, inherent to LLMs, has to be internalised in every expectation. Whether something is allowed to happen is defined elsewhere:

Every tool call an agent makes passes, before execution, through a hook to a central gateway in our operations platform, the application in which we steer, observe and evaluate all agent runs. There it is checked: is the tool approved for this agent? Does the call stay within the tenant it is working for? Is the recipient constellation correct, for instance on a message to a customer? Is the skill in use unchanged, and is the expected structured output being honoured? Is the call accumulating unusually?

If such a check fails, the action never happens, by technical guarantee, provided that all possible execution paths and egress routes are technically forced through this control layer. The agent receives the rule it would have violated, together with a correction proposal, and reformulates.

![Process diagram titled Two control paths between intent and effect, labelled Figure 1, the chain of an autonomous business action. From left to right: a business event such as an email, ticket or order, then the knowledge base holding rules with source and date, then the agent, where the model decides how. Next comes the area headed Harness with two stacked checks: the technical gateway checking tool, tenant, recipient and personal data, and the domain check inside the application covering order, classification and preparation. After that human approval where it adds real safety, and finally execution that is logged and auditable. An arrow leads down from the harness to a box: blocked leads to a visible handling path with rule ID, reason and suggested fix, the agent rephrases and a human decides what is unclear. Two vertical dashed lines mark the privacy boundary, with masking before the model call and checks before writing.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-controlpaths-en.png)

An example from everyday work: a ticket into whose text personal data would find its way, because an agent is trying to create one, say on the briefing of a customer who attached customer data to an email, does not get written. The agent tries to call the create function with its ticket system MCP tool. The model produces a tool call for it. Before our application executes that against the ticket system, the gateway checks payload and permission, for instance for PII. The check knows the rule and rejects the POST, naming the rule and the place. The same mechanism ensures that no agent sends a customer message to an address outside the corresponding tenant, and so on.

And even that is not enough. A generic gateway knows that a tool is allowed. It does not know what the specific action means in business terms. That check therefore sits in the business application itself. On an order approval the application checks whether the order belongs to the assignment in question, whether the recorded classification permits an approval, whether the preparatory steps have happened and whether the same approval has already been scheduled once in this run.

That establishes the separation that makes up the term enterprise grade for us: the model decides how it reaches a goal. The architecture decides within which limits that is allowed to become effective.

### Autonomy is designed per process

Autonomy is not a setting you configure once and apply everywhere. One task ends with a proposal. Others need an approval. Others again run to their goal on their own within defined conditions.

An example from our ticket handling: an agent takes an incoming email to the ticket mailbox, builds a user story, acceptance criteria and a delivery plan from it and creates the ticket. A second agent implements the ticket. It reads the plan, writes code, runs tests and presents the result to the human dev team for quality assurance. If it hits an open question, our agent writes it into the plan as a flagged item, assigns the ticket to the responsible person and waits. Answer, question and decision are transparent and can be settled in direct conversation or in group chats, even in Teams meetings. All communication and all transcripts are analysed after completion and assessed against the most valuable business question there is: how can this query be avoided in future, what has to be done so the harness manages without it on the next run (see also: [What remains after the token?](/en/think-tank/what-remains-after-the-token))

![Screenshot of a delivery plan in the ticket system, in German. Under the heading for the steps towards the goal sit two items marked with a question mark and assigned to a person. In them the agent records that one acceptance criterion cannot be verified without a measure and asks which concrete characteristic it should be checked against, and that a second criterion needs a concrete scenario. Below each question stands the instruction to write the answer in place of the sub-item and then assign the ticket to the Jira user FSE KI, upon which it is checked again. The remaining items of the plan follow, together with a legend explaining that a question mark marks an open point for clarification, which is only permitted while the ticket is being worked on.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-plan-question.png)

If something goes wrong, an escalation applies that is as binding for agents as it is for people. If a task takes longer than planned, if a precondition is missing or if operations are impaired, an agent, a process or a person pulls the “red ripcord” (see the andon cord in the [Toyota Production System](https://en.wikipedia.org/wiki/Toyota_Production_System)): everything stops, we gather in a Teams session, human and machine, and clear the obstacle.

How far autonomy can go depends, for us, on three things: on the possible effect of an action, on the quality of the controls, and on how reliably mistakes are detected. The classic question of the human in the loop shifts with that. It is no longer whether a human is needed in general. It is at which point a human decision adds safety, and where a technically verifiable limit can replace it.

### Data protection lives in the data flow, not in the prompt

A note in the system prompt to treat personal data confidentially is, as mentioned, a request. Data protection instead has to be handled and ensured at the transitions, where data changes location.

Our agents’ mail access naturally delivers sender and recipient. Our rule is: where this information is not required for the purpose of the model call, it does not reach the harness in clear text but is masked or tokenised, the first letter stays, the rest is mas*****. In the customer process, email contents are checked for patterns such as credentials or account numbers before the model call. Generated customer replies are checked for internal or sensitive information before they are passed on. If something is found, the case moves into an internal handling path. Data protection has to be ensured technically. As soon as a harness such as Codex or Claude gets access to an inbox without a prior check, there is a risk of unlawful processing or, in the case of unauthorised disclosure, of a data protection incident. That may sound very German. That I would want to disclose my complaint, my project briefing, my HR assessment report or my weekly personal review to a provider like OpenAI, on the other hand, creates unease and presupposes a trust in transparency that people may think too little about, while otherwise readily entrusting Meta with the most personal insights via WhatsApp, or Apple with at times intimate pictures and messages.

That is why, in our view, the agent traces relevant to security and audit have to be checked and monitored on a risk basis. By that we mean not only the interactions between agent and human, but in particular prompts, tool calls, tool outputs, file and system access, answers and, where the model in use provides them, reasoning summaries. For these logs too, purpose, access and retention period have to be defined. And we go further: if a credential, a secret or an injected instruction is exposed anywhere, it has to be contained. A credential that shows up in such a trace counts as compromised immediately, no matter how it got there, and is replaced, automatically. You may now be thinking: fine, who is careless enough to let secrets be exposed? Here is an example. Claude, with correspondingly far-reaching tool approvals, analysing an order status. Anthropic’s harness gets going, has no direct database access, and a .env file with read-only database access was provided, reachable only over VPN and only through a jump host and an SSH tunnel. That sounds like solid architecture. The agent considers how to get at the order details and accesses the .env via bash, for instance. If the file content is taken into the model context through a read or command output in the process, that content is transmitted to the model provider in use. Consequently: compromised.

![Screenshot of the weekly review of gateway findings for calendar week 38 of 2026, in German. Five rows with case type, check class and recommendation: an attempt to delete a remote branch was correctly blocked, as were real Ansible runs without a check flag, both classified as violations with the note that no action is needed. Three further rows are classified as unclear, because with a truncated command the server access check, the force-push detection and a cross-tenant detection could not be verified conclusively. Every row carries a recommendation and a button to handle the case in Claude or to close it.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-policy-findings.png)

The same principle has to apply to the agents’ memory, by the way. The European Data Protection Board describes privacy by design as an ongoing task: integrated from the start, regularly reviewed for effectiveness, with data minimisation before processing. [1] For us that means: data protection changes the behaviour of the system, not just its wording. And for every use case it is settled which provider processes the data, in which region, for how long and on what contractual basis.

### Claims, disclaimers and the case for a security mindset

The value sits between model, process and harness, not in the concept. The FSE approach outlined here obliges us to examine our pursuit of economical, safe and sustainable operation always with a view to the consequences of the action. A gateway does not prove complete coverage of all execution paths. An audit log does not prove a successful outcome in business terms. A check after an action cannot undo its effect. All our processes prove their effectiveness only once the entire organisation keeps the far-reaching consequences of deviating from the stoic maxim of securing things in mind by default. This precision is not a reservation against autonomy. It is the condition for extending it step by step.

Models get better, so do tools. Access to a capable model will soon set no one apart. As model capabilities converge further, differentiation shifts increasingly to the layer a company builds around the model: its knowledge and where that comes from, its roles and skills, its business rules, its data protection boundaries, its technical authorisations, its governance, and the ability to feed operational experience back into the system. In short, its own harness.

Our ambition is an organisation that lets AI act ever more independently and can still answer six questions at any time:

- On what basis was the action taken?

- Which authority applied?

- Which data was allowed to cross that boundary?

- Which control permitted the action?

- What did we learn from the outcome?

- And who carries the responsibility for what the system is not allowed to decide?

Whoever can answer these questions operates an infrastructure and is no longer a consumer of commodity intelligence from the large, data-hungry frontier labs. Contractually assured with an opt-out, certainly, and yet against the backdrop of [The Hugging Face incident and the road ahead](https://openai.com/index/hugging-face-incident-and-the-road-ahead/) or [An alignment assessment of recent cybersecurity incidents](https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents), Zarathustra deserves a mention:

Perhaps that is exactly why AI is less the question of what machines will be able to do, and more of what people and their organisations make of it.

AI may not be Zarathustra’s overman. It may force us to answer anew what people should not delegate to machines.

Entrepreneurial action means taking things into your own hands and acting autonomously with all the consequences. We want to urge emphatically that these new, powerful tools, which will soon deliver omnipresent intelligence at an unimaginable pace, are understood as such, and that we all deploy them in a way that keeps us aware of how commoditisable we are.

![Infographic titled The model decides how. The harness decides how far, headed The secure AI harness. At the top a chain of four steps: business event, knowledge base and agent, gateway and domain check, approval or execution. Below a table titled What the install ships, and what is missing, with the columns After installation and Enterprise grade at FSE. Four rows: how the agent knows what applies, from the prompt and open files versus a versioned knowledge base with source, date and a governance process. What may happen technically, whatever the local permission list allows versus every tool call passing a central policy gateway that checks before anything takes effect. What happens to personal data, it enters the context as soon as it is read versus masking and tokenisation at the boundaries. How a change goes live, edit a file and save versus merge request, human approval, regression tests and evals. The conclusion below: a rule in the context window is a request, whether an action happens is decided by the control layer that enforces every execution path. At the foot three cards under the heading Six questions, answerable at any time: on what basis the system acted and which authority applied, which data was allowed across the boundary and which control permitted it, what was learned from the outcome and who is accountable for what the system must not decide.](https://fse-group.de/media/think-pieces/20260915_thinktank-harness-overview-en.png)

#### Sources

- [1] European Data Protection Board: *Guidelines 4/2019 on Article 25, Data Protection by Design and by Default*, version 2.0, 20 October 2020.

- [2] Anthropic: *Claude Code documentation*, sections on permissions, hooks and managed settings, accessed in September 2026.

- [3] European Union: *General Data Protection Regulation*, in particular Art. 5, Art. 6, Art. 25, Art. 28 and Art. 32.

- [4] Anthropic: *Documentation on Claude Code permissions as well as extended thinking and thinking summaries*, accessed in September 2026.

- [5] Andrej Karpathy: *Publications on the LLM wiki concept*, 2026.