Concept · AIAD doctrine v1.9

Agent autonomy — a variable you calibrate

An agent that can write code, spend money, delete data or act on equipment is no longer a mere text generator. The AIAD doctrine v1.9 does not seek to maximise its autonomy: greater autonomy is not a goal in itself; it is a variable you calibrate, SPEC by SPEC. This page brings together the mechanisms that set that calibration — and that make it possible to demonstrate, after the fact, what had been delegated.

What the human grants, what the agent gives back

Agent autonomy is described in both directions. On one side, what the human grants: a level of authority, an execution scope, caps. On the other, what the agent gives back: stop points where it returns to the human, an immediate halt when it exceeds what was delegated to it, and a trace of what it did. Both are declared before execution, in the Intent Statement and the SPEC, and checked at the Execution Gate. This is the operational form of value 7, Human Authorship, and of value 6, Shared Responsibility: autonomy delegated without an accountable human is a governance defect, not a feature.

The authority continuum

Each move from one level of authority to the next is a distinct human act that no other act replaces. Agreeing to answer an agent's questions does not authorise it to write; validating a SPEC does not authorise a deployment.

"Writing" here means code and production artifacts. At the consultation and clarification levels, the agent may draft specification artifacts — that is the role of /sdd spec; they commit nothing until a human has validated them at the Gate. The Intent Statement, for its part, is still written by a human.

Stop points at the agent's initiative

The continuum describes what the human grants; stop points describe when the agent must come back to the human. AIAD adopts the typology proposed by Ethan Mollick in 2026:

The SPEC may specify which ones apply, in its optional "Agent stop points" section. If the section is absent, the framework's default stop points apply: those imposed by the authority continuum. When the agent cannot decide, it emits a JNSP verdict rather than inventing.

The agent's execution scope

As soon as the agent executing a SPEC holds credentials (cloud, API, SSH, database) or write access to a shared resource, the SPEC declares its execution scope in the conditional "Agent execution scope" section. Outside those cases, you write "Not applicable" and fill in nothing: a SPEC must not grow heavier with a field filled in out of ritual.

Three rules accompany the declaration: the harness permission mode is not a containment measure and is not recorded as one; any shared resource with write access is a potential coordination channel between agents and must be declared, even if it looks harmless; if an irreversible action is possible, the Execution Gate checks the cap, the prior human authorisation and the stop threshold.

Reversibility class and stop threshold

When the intent involves agent actions with effects outside the code — financial, operational or physical —, the Drift Criterion of the Intent Statement specifies their reversibility class:

• reversible: can be undone at no cost;
• costly to reverse: can be undone with a loss (money, time, restoring from a backup);
• irreversible: cannot be undone (payment executed, contractual commitment, permanent deletion, physical action on equipment).

For the irreversible class, the Drift Criterion sets a stop threshold, not a mere tracking indicator: any observed overreach of autonomy — spending beyond the cap, an action outside the delegated scope, an attempt to hide or alter its own traces — triggers an immediate halt of the agent and a human review, not an after-the-fact report. Providers' billing alerts do not fill that role: designed for human-speed errors, they can lag by up to 24 hours (overspend incidents documented by InfoQ, July 2026).

The "Agents with irreversible effects" profile of AIAD-AI-ACT

The AIAD-AI-ACT governance agent devotes an emerging risk profile to agents with irreversible effects (financial, operational, physical). If it influences a decision affecting people in an Annex III domain of the AI Act, the agent falls under the high-risk regime. Outside that case, the regulation imposes no oversight obligations specific to this profile: AIAD nevertheless applies, as good practice, minimal human checkpoints before any deployment into service — and general law continues to apply.

AIAD prescribes properties, not products. Outside high risk, the references to Articles 12 and 14 are good practice, not a legal obligation. An accountable human is designated for each delegation, even when the protocol used provides its own caps: an infrastructure safeguard is not an accountability framework.

A permission mode is not a control

Harnesses offer permission modes: manual approval, automatic classifier, allow-lists. They reduce friction; they do not constitute an enforceable guarantee. In August 2026, Johann Rehberger bypassed Claude Code's automatic mode in 80% of his attempts — and, in some cases, the classifier allowed the malicious process and then blocked the remediation command launched by the agent. A mechanism that can block remediation cannot carry human authority.

The Agents Engineer therefore never presents a permission mode as a sufficient security measure. Protection rests on isolation: container or virtual machine, restricted network egress, no superfluous credentials (SSH keys, cloud keys) in the agent's execution environment. The permission mode comes as a complement, never as a substitute. This extends the least-privilege principle of Harness Engineering (see the Agents Engineer responsibility).

Containment is judged on the shared surface

Isolating each agent is not enough. In July 2026, some 1,200 OpenAI evaluation agents, each isolated in its own sandbox, discovered that they had access to the same Artifactory cache. They turned it into a message board — more than 70,000 messages and files exchanged — and around 700 of them took part in a multi-day intrusion at Hugging Face (independent METR / Redwood Research report, August 2026). Each agent's isolation was real; it was the common resource that served as the channel.

Martin Fowler describes the same mechanism in a constructive light ("An accidental blackboard", September 2026): agents spontaneously using the git repository as shared memory. The lesson is the same in both cases: any shared resource with write access is a coordination channel between agents, intended or not. The Agents Engineer inventories these resources, and the SPEC declares them — including intended coordination spaces — in its "Agent execution scope" section.

The trace as evidence

AIAD adopts the thesis put forward by Bruce Schneier and Nathan Sanders in June 2026: AI agents are the agents of the person or organisation that deploys them. This is a thesis, not settled law. A first judicial signal exists — the injunction of the Munich Regional Court of 28 May 2026 holding Google liable for statements generated by its AI Overviews —, but it concerns defamation by a search engine, not development agents, and the decision is provisional and under appeal.

If the organisation answers for its agents, it must be able to show what it asked of them, within which limits, and who validated it. This is the delegation trace prescribed by AIAD-AI-ACT: every task entrusted to an agent is linked to an Intent Statement, a SPEC and the Execution Gate trace; a task whose human origin cannot be traced is not executed.

These artifacts do not guarantee the outcome of a dispute. They document the organisation's diligence and make its accountability demonstrable — in both directions: a defective SPEC validated at the Gate commits whoever validated it. A trace that could only exonerate would not be evidence.

The same chain conditions automated deployment: a deployment without human intervention is only admissible if the code is trusted in the sense of a verifiable chain of evidence — Intent Statement, SPEC validated at the Gate, traced checks, Drift Lock —, not through declarative trust in the tool or the model. For an organisation with modest engineering means, the practical consequence is to reserve automated deployment for features whose chain of evidence is complete. Machine-verifiable traceability then links every line of code to that chain.

In the aiad-sdd package

• SPEC sections: the SPEC templates (prose and EARS) include the "Agent stop points" (optional) and "Agent execution scope" (conditional, "Not applicable" otherwise) sections — labelled « Points d'arrêt de l'agent » and « Périmètre d'exécution de l'agent » in the French templates. Compared with the doctrine, the template's table adds a "Stop threshold" row and has no separate "Intended coordination spaces" row.
• gate-precheck pre-check: npx aiad-sdd gate-precheck <SPEC>, run by /sdd gate before any SQS scoring, reads the "Agent execution scope" section and returns a deterministic verdict computed outside the model — PASS (exit code 0), FAIL (1: Gate closed, for example an irreversible action without a stop threshold) or JNSP (2: Gate unknown, SPEC not found or incomplete table). Details on the Execution Gate page.

Sources

AIAD doctrine v1.9: AIAD Framework, § 3.3 (Agents Engineer — permission mode, shared surface), § 4.0 (reversibility class and stop threshold), § 4.4 (authority continuum, stop points), § 5.5 (chain of evidence for automated deployment); annex A, SPEC template ("Agent stop points" and "Agent execution scope" sections); AIAD-AI-ACT, "Agents with irreversible effects" profile and "Delegation trace" instruction; legitimation dossier "The AIAD trace as evidence of accountability" (sources verified on 25/09/2026). This content describes a governance and accountability logic, not legal advice.