ThirdOcular › Agent Readiness Standard › v1.0

Agent Readiness Standard

controls, pass criteria and evidence rules for production agentic AI systems

ARS v1.0 draft 41 checks 8 tiers ThirdOcular LLC 2026-08-05

Content hash sha256 · json-sorted-keys-no-hash-field
12309637f0a716f9923204a4338c07acca5107a3cb9aa02b0a20b48902926d9c

Computed over this document with the hash object removed, every object's keys sorted recursively, serialised with no whitespace, sha256 of the UTF-8 bytes, lowercase hex. Array order is preserved. A citation to ARS-1.0-01 resolves to a specific text, and a version number alone is a promise enforced by nothing.

Standing

No second party has applied this document without the authoring party's involvement. Until that happens it is a rubric with a versioned changelog, not a standard. It is written to a publishable bar and is published as a draft so that it can be cited and argued with. The independently_applied flag may only become true once a second party has assessed a system against this document without us, and no score produced under this version is a certification of anything.

checks in total

[S] static — readable from code and config

[R] runtime — needs a running system

[G] governance — interview and document review

1 Identity & Access Propagation ARS-01–ARS-05 · ×1.5
2 Tool-Call Governance ARS-06–ARS-12 · ×1.5
3 Audit & Traceability ARS-13–ARS-17 · ×1.5
4 Failure, Recovery & Control ARS-18–ARS-23 · ×1
5 Security Surface ARS-24–ARS-29 · ×1.5
6 Cost & Resource Containment ARS-30–ARS-32 · ×1
7 Evaluation & Monitoring ARS-33–ARS-37 · ×1
8 Data Handling & Compliance ARS-38–ARS-41 · ×1

What this applies to

Software systems in which a language model selects and invokes tools, retrieves data, or takes actions against other systems on behalf of a human user or an automated trigger, in a production or production-bound deployment.

It does not cover

single-turn text generation with no tool access and no retrieval, where most of Tiers 1 through 4 have no subject
model training, fine-tuning and data curation pipelines, which are a different control surface
research prototypes with no production data and no production credentials
chat interfaces whose only side effect is returning text to the person who asked, and which hold no credential of their own
the question of whether the model is any good at the task, which is a capability question and not a readiness one

What decides whether a system is in scope

Authoritative: the system holds or delegates a credential to reach another system; model output selects which action executes, rather than only what text is displayed; an execution loop can invoke a tool more than once without returning to a human.

Never: the presence of the word agent in a product name, a repository name, or a job title, none of which is a statement about architecture; the model vendor, which determines none of these controls.

What this does not adjudicate

A standard that does not bound itself will be read as bounding nothing.

Subject	Why not
whether the agent is good at its job	Every control here is about what happens when the agent is wrong, compromised, or looping. A system can pass all 41 and still produce useless output. Readiness and capability are different questions and conflating them is how a security review gets answered with a demo.
model safety behaviour and alignment properties of the underlying model	Those are properties of a vendor's model that the deploying organisation cannot inspect, cannot version independently, and cannot remediate. This standard assesses the architecture the model is deployed inside, which is the part the deploying organisation controls and is accountable for.
general application security, infrastructure hardening and enterprise IT controls	Network segmentation, endpoint management, patching and the rest are covered by established frameworks that already have auditors. Duplicating them here would produce a document nobody finishes reading and would dilute the controls that are specific to agents.
regulatory classification of the AI system under any specific regime	Whether a deployment is high-risk under a given regulation is a legal determination about purpose and context, made by counsel. This document maps controls to mechanisms so that determination can be made against evidence, and takes no position on the determination itself.
vendor and model selection	The controls are written to be model-agnostic on purpose. A standard that scored vendors would be obsolete on the next release and would be read as a procurement recommendation, which is not what a control assessment is.
cost efficiency as an optimisation goal	Tier 6 asks whether spend is bounded and attributable, never whether it is low. An agent that costs a great deal and is contained passes; a cheap one that cannot be stopped fails. Efficiency is a business question with no defensible pass line.

How to read a check

Every check carries a pass criterion, the way it fails in production, and one automation flag naming the instrument that can read it. The flag is not a severity: an R · runtime check is not more or less serious than an S · static one, it is read differently.

Flag	Instrument	What reads it
S	static	Statically checkable from code and configuration. Automatable by the ars-check harness against a repository or config directory, with no access to a running system.
R	runtime	Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.
G	governance	Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Tier 1. Identity & Access Propagation

5 checks · weighted ×1.5 in the overall mean. A failure here means any user can reach any data the agent can reach. It is the largest blast radius in the set and the hardest to retrofit.

ARS-01

End-user identity propagates to every downstream call

R · runtime

Pass

Every tool call, API call, and data access executed by the agent carries the originating user's identity, not a shared service identity, and downstream authorization is evaluated against that user.

In production, this fails like this

Agents running on a god-mode service account mean any user can reach any data the agent can. This is the single most common finding in enterprise agent deployments and the first thing a security review board asks about.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-01

ARS-02

Least-privilege tool credentials

S · static

Pass

Each tool/connector is provisioned with the minimum scopes required for its declared function; no wildcard or admin-level grants where a narrower scope exists.

In production, this fails like this

A read-only summarization agent holding write scopes becomes a write agent the moment a prompt injection lands.

What the harness can and cannot establish

Static ceiling: 1 of 2. A wildcard or admin scope is conclusive evidence of failure. Its absence is not evidence of least privilege, because minimality is a judgement about what the tool actually needs and static analysis does not know that.

A pass means

A pass means no wildcard or administrative grant was found in the scope declarations that were read. It does not mean the scopes are minimal for the function, which requires knowing the function.

Signals

wildcard scope literals in connector and OAuth configuration
administrative role names bound to agent service principals
a single credential shared across tools with materially different functions
declared scopes absent entirely, which is scored as no mechanism rather than as narrow

Cite as ARS-1.0-02

ARS-03

No secrets in prompts, context, or logs

S · static

Pass

Static scan finds no API keys, tokens, connection strings, or credentials in prompt templates, system prompts, config files committed to the repo, or log output paths. Secrets are injected at runtime from a managed store.

In production, this fails like this

Context windows get logged, cached, and replayed. A secret in a prompt is a secret in your observability stack forever.

What the harness can and cannot establish

Static ceiling: 2 of 2. Secret scanning is a static discipline and this criterion is written as a static scan. A found credential settles the check at 0; a clean scan combined with a managed-store reference is the evidence the criterion asks for.

A pass means

A pass means no credential literal was found in the files that were read, and a managed secret store is referenced. It says nothing about files outside the scanned tree, about history, or about secrets that entered at runtime.

Signals

high-entropy string literals and known credential prefixes in prompt templates and config
connection strings with embedded passwords
credential literals inside files whose contents are assembled into a prompt
a reference to a managed secret store or runtime secret injection, required for a 2
log configuration that writes full prompt or context payloads to a persistent sink

Cite as ARS-1.0-03

ARS-04

Session and credential lifetime bounds

S · static

Pass

Agent sessions and their delegated credentials have explicit TTLs; long-running agents re-authenticate rather than holding immortal tokens.

In production, this fails like this

An agent that never re-auths is an agent whose stolen token never expires.

What the harness can and cannot establish

Static ceiling: 1 of 2. A TTL constant in configuration is a declaration. Whether the runtime honours it, and whether a long-lived process actually re-authenticates rather than caching a token past its stated life, are runtime facts.

A pass means

A pass means an explicit lifetime bound was found in configuration. It does not mean the bound is enforced, that expiry is honoured, or that re-authentication succeeds.

Signals

explicit TTL, expiry or max-age settings on session and token configuration
a refresh or re-authentication path in the agent loop
non-expiring credential types such as static personal access tokens bound to the agent
session objects created with no lifetime setting at all

Cite as ARS-1.0-04

ARS-05

Separation of agent identity from human identity in audit records

R · runtime

Pass

Audit records distinguish "user X asked" from "agent acting for user X did" — both identities present, never conflated.

In production, this fails like this

When something goes wrong, "who did this" must have two answers. Systems that record only one cannot support incident response or legal review.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-05

Tier 2. Tool-Call Governance

7 checks · weighted ×1.5 in the overall mean. Tool calls are where an agent stops being a text generator and starts changing the world. Every irreversible action in the system passes through this tier.

ARS-06

Closed tool registry

S · static

Pass

The agent can only invoke tools from an explicit, versioned registry; no dynamic tool loading from model output, no eval/exec of generated code against production systems without a sandbox boundary.

In production, this fails like this

Dynamic tool acquisition converts a prompt injection into arbitrary code execution.

What the harness can and cannot establish

Static ceiling: 1 of 2. A registry file proves a registry exists. Only runtime can establish that a tool name outside it is refused rather than resolved by a fallback path, and the fallback is exactly where this control fails.

A pass means

A pass means an explicit tool registry was found and no dynamic-execution sink reachable from model output was found in the scanned tree. It does not establish that the dispatcher refuses a tool name absent from the registry.

Signals

an explicit, enumerable tool registry or manifest, versioned
eval, exec, Function constructor, or dynamic import applied to model output
shell invocation constructed from model output without an argument allowlist
tool resolution by string lookup against an open namespace rather than a closed map
a sandbox boundary declared around any code-execution tool

Cite as ARS-1.0-06

ARS-07

Tool schemas are maximally constrained

S · static

Pass

Tool input schemas use enums, patterns, ranges, and required fields rather than free-form strings wherever the domain permits; no additionalProperties: true on production tool schemas.

In production, this fails like this

A free-text query parameter on a database tool is a SQL injection surface with a language model as the injector.

What the harness can and cannot establish

Static ceiling: 2 of 2. Schema permissiveness is entirely a property of the schema document. There is no runtime fact that makes a schema with additionalProperties true into a constrained one. This is the check static analysis can settle most completely.

A pass means

A pass means the tool schemas as written constrain their inputs. This is a property of the schema text and is fully settled by reading it. It does not mean the runtime validates against the schema.

Signals

additionalProperties true, or absent on an object schema in a strict-mode toolchain
string parameters with no enum, no pattern and no maxLength on tools that reach a datastore or a network
numeric parameters with no minimum or maximum
required arrays absent, making every parameter optional
enums, patterns, ranges and required fields present, which is what a 2 is awarded for

Cite as ARS-1.0-07

ARS-08

Destructive actions are enumerated and gated

S · static

Pass

A written inventory exists of every tool action that creates, modifies, deletes, sends, or spends. Each is classified, and each classification maps to a gating policy (auto-allow / human approval / prohibited).

In production, this fails like this

If nobody can produce the list of what the agent can destroy, the answer is "more than you think."

What the harness can and cannot establish

Static ceiling: 2 of 2. The criterion asks whether a written inventory exists and is classified. That is a document property, readable in full. Its completeness against the tool registry is also checkable statically by set comparison.

A pass means

A pass means the inventory exists, classifies each listed action, and maps each classification to a gating policy, and that its entries cover the side-effecting tools found in the registry. It does not mean the gating policy is enforced, which is ARS-09 and ARS-11.

Signals

an inventory document or data file enumerating side-effecting actions
a classification on each entry, drawn from a closed set
a gating policy mapped to each classification
side-effecting tools present in the registry but absent from the inventory, which caps the score at 1 with the gap named
an inventory that exists but classifies nothing, which is a list rather than an inventory

Cite as ARS-1.0-08

ARS-09

Human approval gate on irreversible or high-impact actions

S · static

Pass

Actions classified high-impact route through an explicit human approval step (e.g., a three-state approve/modify/reject pattern) before execution, and the approval is recorded with approver identity.

In production, this fails like this

"The agent sent it before anyone saw it" is the failure mode that ends agent programs. Approval must be structural, not a prompt instruction.

What the harness can and cannot establish

Static ceiling: 1 of 2. Static analysis can find an approval mechanism and can tell code from a prompt string. It cannot establish that no path reaches execution around the gate, and an unenforced gate and an enforced one look identical in a diff.

A pass means

A pass means an approval mechanism exists in code and records an approver identity. It does not mean execution is impossible without it.

Signals

an approval state machine with at least approve, modify and reject
approver identity captured and persisted with the decision
the gate implemented in orchestration code rather than requested in a system prompt, which is the difference between a 1 and a 0
high-impact actions from the ARS-08 inventory with no reference to the approval path
an approval flag that defaults to auto-approve

Cite as ARS-1.0-09

ARS-10

Approval fatigue is designed against

G · governance

Pass

Approval volume per approver is measured and bounded; low-risk actions are auto-allowed by policy so that human review capacity is spent where it matters.

In production, this fails like this

A gate that fires 400 times a day is a gate everyone clicks through. Rubber-stamp approval is worse than no approval because it launders accountability.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-10

ARS-11

Tool-call authorization is enforced server-side

R · runtime

Pass

The gateway/backend independently enforces which tools a given agent+user pairing may call; the model's own restraint is not the enforcement mechanism.

In production, this fails like this

System-prompt-based restrictions ("you may not call X") are suggestions. Enforcement lives in infrastructure or it doesn't exist.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-11

ARS-12

Cross-tool data flow policy

G · governance

Pass

A written policy governs which tool outputs may flow into which tool inputs (e.g., untrusted web content may not flow into an email-send tool without human review), and the orchestration layer enforces it.

In production, this fails like this

Exfiltration via tool chaining — read sensitive data with tool A, transmit it with tool B — is the canonical agent attack and requires flow-level, not tool-level, policy.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-12

Tier 3. Audit & Traceability

5 checks · weighted ×1.5 in the overall mean. Without this tier no other tier can be verified after the fact, and no incident can be investigated. It is the tier that makes the others reviewable.

ARS-13

Immutable audit plane

R · runtime

Pass

Every agent action (prompt, tool call, tool result, approval, final output) is written to an append-only/WORM store that the agent itself has no write-modify or delete permission on.

In production, this fails like this

An agent with delete rights on its own audit log is an agent with an alibi.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-13

ARS-14

End-to-end correlation IDs

S · static

Pass

A single correlation ID links user request → agent reasoning trace → every tool call → every downstream system record, and it is queryable.

In production, this fails like this

Without correlation, incident response is archaeology. "Which agent run touched this record" must be a query, not an investigation.

What the harness can and cannot establish

Static ceiling: 1 of 2. Static analysis can see an identifier created and passed. Whether it survives into every downstream record, and whether anything indexes it, are properties of systems outside the repository.

A pass means

A pass means a correlation identifier is generated and threaded through the code paths that were read. It does not mean it reaches downstream system records, and it does not mean it is queryable.

Signals

a correlation, trace or run identifier generated once per user request
that identifier passed into tool invocations rather than regenerated per call
the identifier present in log and audit write paths
tool call sites that log without it, which is where the chain breaks
per-call identifiers with no parent, which produce records that cannot be joined

Cite as ARS-1.0-14

ARS-15

Reasoning trace retention with access controls

G · governance

Pass

Model reasoning/intermediate outputs are retained per a defined policy, access-controlled (traces can contain sensitive data), with defined retention and deletion schedules.

In production, this fails like this

Traces are discovery-relevant records. Retaining them forever and retaining them for no time are both legal problems; the policy must be deliberate.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-15

ARS-16

Full replayability of any agent run

R · runtime

Pass

Given a run ID, the team can reconstruct exactly what the agent saw, decided, and did — inputs, model version, prompt version, tool versions, outputs.

In production, this fails like this

"We can't reproduce what happened" is unacceptable to every review board and every regulator.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-16

ARS-17

Prompt and configuration versioning

S · static

Pass

System prompts, tool definitions, and orchestration config are version-controlled; every production run records which versions it executed under.

In production, this fails like this

Prompts edited live in a console are unversioned production code. Behavior changes with no diff and no rollback.

What the harness can and cannot establish

Static ceiling: 2 of 2. Whether a prompt lives in a version-controlled file or is fetched from a console at runtime is settled by reading the code. Both halves of the criterion, the versioning and the recording, are visible statically.

A pass means

A pass means prompts, tool definitions and orchestration config are files under version control, and the run record captures a version identifier for them. It does not mean the recorded identifier is correct at runtime.

Signals

system prompts stored as files in the repository rather than fetched from a remote console at runtime
tool definitions and orchestration config committed alongside them
a prompt or config version identifier written into the run record
prompts assembled from a remote configuration service with no pinned version, which is unversioned production code
prompt files present but no version stamped on runs, which is the difference between a 1 and a 2

Cite as ARS-1.0-17

Tier 4. Failure, Recovery & Control

6 checks · weighted ×1 in the overall mean. Serious, and weighted at parity because a mature organisation can add most of these controls after deployment without re-architecting.

ARS-18

Kill switch with defined blast radius

R · runtime

Pass

A documented, tested mechanism halts the agent (per-session, per-agent, fleet-wide) within a defined time bound, and in-flight actions have defined disposition (complete/abort/rollback).

In production, this fails like this

The question is never whether you'll need to stop it; the question is whether stopping it is a runbook or a scramble.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-18

ARS-19

Idempotency on side-effecting operations

S · static

Pass

Retried or duplicated tool calls cannot double-execute side effects (idempotency keys, dedup at the tool boundary).

In production, this fails like this

Agents retry. Networks fail. Without idempotency, "send the payment" runs twice.

What the harness can and cannot establish

Static ceiling: 1 of 2. An idempotency key can be seen in code. Whether it is derived stably, whether the deduplication window is long enough, and whether the receiving system enforces it are all runtime facts, and each of them silently defeats the control.

A pass means

A pass means an idempotency mechanism is present on side-effecting tool paths. It does not mean it is correct, that the key is stable across retries, or that the downstream system honours it.

Signals

idempotency keys or request identifiers sent with side-effecting calls
deduplication at the tool boundary keyed on request identity
retry logic wrapping side-effecting calls with no idempotency key, which is the failure this check names
keys derived from a timestamp or a random value per attempt, which is a key that changes on the retry it exists to survive

Cite as ARS-1.0-19

ARS-20

Bounded retries and loop detection

S · static

Pass

Retry counts, recursion depth, and agent-loop iteration counts have hard ceilings enforced outside the model; repeated identical tool calls trip a breaker.

In production, this fails like this

An agent in a loop is a denial-of-service attack you are running against yourself, billed by the token.

What the harness can and cannot establish

Static ceiling: 1 of 2. A maximum-iteration constant is visible. Whether every loop in the system is governed by one, and whether the breaker for repeated identical calls actually trips, are not settled by finding a constant.

A pass means

A pass means explicit ceilings on retries and loop iterations are present in orchestration code. It does not mean the ceilings are reached safely or that a breaker exists for repeated identical calls unless that was separately found.

Signals

an explicit maximum iteration or step count on the agent loop
bounded retry counts on tool and model calls
a breaker on repeated identical tool calls
while loops around model calls with no counter, which is the unbounded case
a ceiling stated in the system prompt rather than enforced in code, which is at most a 1 and usually a 0

Cite as ARS-1.0-20

ARS-21

Graceful degradation path

G · governance

Pass

For each critical agent function, a documented fallback exists when the model, a tool, or a dependency is down — and the fallback has been exercised.

In production, this fails like this

If the agent is in a business-critical path and the fallback is "call the person who used to do this," that person had better still know how.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-21

ARS-22

Rollback/compensation for committed actions

R · runtime

Pass

For each destructive action class, a compensation procedure exists (undo, reversal, manual remediation runbook) and has been tested at least once.

In production, this fails like this

Approval gates reduce the frequency of bad actions; compensation bounds their cost. You need both.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-22

ARS-23

Timeout discipline at every boundary

S · static

Pass

Model calls, tool calls, and end-to-end sessions all have explicit timeouts; no unbounded waits.

In production, this fails like this

Hung agent sessions accumulate silently — holding credentials, locks, and cost the entire time.

What the harness can and cannot establish

Static ceiling: 1 of 2. A call site with no timeout is a definite finding. A clean read is not proof of coverage, because a boundary the scan did not reach is indistinguishable from a boundary that has a timeout.

A pass means

A pass means explicit timeouts were found on the outbound call sites that were read. It does not mean every boundary in the system has one, because static analysis cannot enumerate every boundary.

Signals

explicit timeouts or abort signals on model client construction and invocation
timeouts on outbound HTTP and database calls made by tools
an end-to-end session or run deadline
fetch, request and client calls with no timeout and no abort signal, reported individually with their locations
a default timeout set at the client rather than per call, which counts

Cite as ARS-1.0-23

Tier 5. Security Surface

6 checks · weighted ×1.5 in the overall mean. Prompt injection and exfiltration are trust-boundary properties of the architecture. A failure here is not patchable by a model upgrade and usually requires the prompt assembly to be rebuilt.

ARS-24

Untrusted content is segregated and labeled

S · static

Pass

Content from external/untrusted sources (web, email, user uploads, third-party APIs) is structurally distinguished from operator instructions in the prompt assembly, and the orchestrator treats instructions found inside it as data.

In production, this fails like this

Prompt injection is not a model bug to be patched; it is a trust-boundary property of the architecture. If untrusted text and operator instructions are concatenated undifferentiated, the injection surface is total.

What the harness can and cannot establish

Static ceiling: 1 of 2. Undifferentiated concatenation of untrusted content into a prompt is conclusive: the injection surface is total and the check is 0. Structural separation caps at 1, because whether the boundary holds is a behavioural property that only adversarial testing establishes.

A pass means

A pass means untrusted content is structurally separated from operator instructions in the prompt assembly code. It does not mean the model honours the separation, which is ARS-25 and is tested, not read.

Signals

tool results and retrieved content placed in a distinct structural position from operator instructions rather than interpolated into the system prompt
an explicit labelling or wrapping function applied to external content
string concatenation or template interpolation of fetched web, email or file content directly into the instruction text, which is the total-surface case
a stated rule in the assembly code that instructions inside external content are data
user uploads and third-party API responses treated the same way as retrieved web content

Cite as ARS-1.0-24

ARS-25

Injection resistance is tested, not assumed

R · runtime

Pass

A maintained adversarial test suite (direct injection, indirect injection via tool results, exfiltration chains) runs against the production configuration, with results tracked across model/prompt versions.

In production, this fails like this

Every model upgrade re-rolls the dice on injection behavior. Untested resistance is unmeasured resistance.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-25

ARS-26

Output handling prevents downstream injection

S · static

Pass

Agent output rendered into UIs, emails, or documents is encoded/sanitized (XSS, markdown link exfiltration, HTML smuggling); agent output executed as code or queries passes through the same review gates as human-authored code.

In production, this fails like this

The agent's output is attacker-influenced input to every system that consumes it.

What the harness can and cannot establish

Static ceiling: 1 of 2. An unescaped sink reached by model output is a definite finding. The converse is not settled statically: a sanitiser can be present and wrong, and sinks outside the scanned tree are invisible.

A pass means

A pass means agent output passes through an encoding or sanitisation step before reaching a rendering sink in the code that was read. It does not establish that the sanitiser is correct or that every sink was found.

Signals

model output reaching innerHTML, dangerouslySetInnerHTML, or an unescaped template sink
model output written into an email body or document without encoding
markdown rendered from model output with image and link URLs unrestricted, which is the exfiltration channel
an escaping or sanitising function applied on the path from model output to sink
model output executed as a query or as code without passing a review gate

Cite as ARS-1.0-26

ARS-27

Data exfiltration channels are enumerated and constrained

G · governance

Pass

A written inventory of every channel by which the agent can transmit data outward (messages, emails, HTTP calls, file writes, URL rendering) exists, with per-channel policy on what data classes may flow.

In production, this fails like this

You cannot prevent exfiltration through channels you haven't listed. Markdown image URLs count as a channel.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-27

ARS-28

Model and dependency supply chain is pinned

S · static

Pass

Model versions are pinned and upgrades are deliberate events with eval gates; third-party MCP servers, libraries, and tool packages are version-pinned and provenance-reviewed.

In production, this fails like this

An auto-upgrading model is a production deployment nobody approved. An unreviewed MCP server is third-party code with your credentials.

What the harness can and cannot establish

Static ceiling: 2 of 2. Pinning is a text property of manifests and configuration. A floating model alias or an unpinned dependency range is visible in full, and no runtime fact turns a range into a pin.

A pass means

A pass means model identifiers and dependency versions are pinned as written. It does not cover provenance review, which is a process, and it does not establish that an upgrade would be gated by evals.

Signals

model identifiers pinned to a specific version rather than a floating alias such as latest
a dependency lockfile present and committed
dependency ranges rather than exact versions in the manifest
third-party MCP servers referenced by a moving tag or an unpinned remote source
tool packages installed from a URL or a branch rather than a versioned release

Cite as ARS-1.0-28

ARS-29

Tenant and context isolation

R · runtime

Pass

In multi-user or multi-tenant deployments, no channel exists by which one user's data, memory, or context can surface in another user's session (including via shared caches, vector stores, and memory systems).

In production, this fails like this

Shared pgVector namespaces and shared conversation memory are the two places this fails quietly.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-29

Tier 6. Cost & Resource Containment

3 checks · weighted ×1 in the overall mean. The most common first production incident and the most preventable, but a cost runaway is recoverable in a way a data exposure is not.

ARS-30

Hard budget ceilings per session and per period

S · static

Pass

Token/dollar budgets are enforced per-run, per-user, and fleet-wide by infrastructure (not by prompt instruction), with alerting before ceilings and hard stops at them.

In production, this fails like this

Cost incidents are the most common first production incident for agent programs, and the most preventable.

What the harness can and cannot establish

Static ceiling: 1 of 2. A budget constant is a declaration. Whether the run actually halts at the ceiling, and whether alerting fires before it, are runtime behaviours that a configuration value does not establish.

A pass means

A pass means budget ceilings are declared in configuration or enforced in code. It does not mean the hard stop fires, and it does not cover the fleet-wide scope unless that was separately found.

Signals

per-run token or cost ceilings enforced in orchestration code
per-user and aggregate budget configuration
a hard stop rather than a warning at the ceiling
a budget stated in the system prompt, which is not enforcement and scores 0 for this criterion
token accounting present with no ceiling attached to it

Cite as ARS-1.0-30

ARS-31

Cost attribution to business unit of work

G · governance

Pass

Spend is attributable per agent, per user, per task type — such that "what does one completed X cost us" is answerable.

In production, this fails like this

Unattributed spend cannot be optimized and cannot survive a budget review. Programs die at renewal for lack of this number.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-31

ARS-32

Resource quotas on downstream systems

S · static

Pass

The agent's access to downstream systems is rate-limited independently of any limits the model provider imposes, sized so a runaway agent cannot degrade shared systems.

In production, this fails like this

An agent hammering an internal API is an internal DDoS with valid credentials.

What the harness can and cannot establish

Static ceiling: 1 of 2. A rate limiter is visible in configuration or code. Whether it is sized so a runaway agent cannot degrade a shared system is a capacity judgement about systems the scan cannot see.

A pass means

A pass means an independent rate limit on the agent's downstream access was found. It does not establish that the limit is sized correctly for the systems being protected.

Signals

rate limiting or concurrency caps applied to the agent's outbound calls
limits configured independently of the model provider's own throttling
per-downstream-system quotas rather than one global limit
unbounded parallel fan-out over tool calls
reliance on the provider's rate limit as the only bound, which is a limit sized for the provider and not for the downstream system

Cite as ARS-1.0-32

Tier 7. Evaluation & Monitoring

5 checks · weighted ×1 in the overall mean. Determines whether the other tiers stay true over time. Weighted at parity because it is a rate of decay rather than a present exposure.

ARS-33

A versioned eval suite exists and gates deployment

S · static

Pass

A maintained eval suite covering the agent's core tasks (success cases, failure cases, refusal cases, adversarial cases) runs on every prompt/model/tool change, with defined pass thresholds that block promotion on regression.

In production, this fails like this

Without eval gates, every prompt tweak is an untested production deploy. "It seemed fine in the console" is not a release process.

What the harness can and cannot establish

Static ceiling: 2 of 2. Existence, CI wiring and a blocking threshold are all text: eval case files, a CI workflow that runs them, and a failure condition. Whether the suite is any good is a quality judgement this check does not make and says so.

A pass means

A pass means an eval suite exists, is wired into CI, and CI is configured to fail below a threshold. It does not mean the evals are good, and a suite that passes trivially would read the same way here.

Signals

eval case files present and enumerable
cases covering success, failure, refusal and adversarial classes rather than success only
a CI workflow or pipeline step that runs the suite
a pass threshold that fails the build, rather than a step that reports and continues
an eval suite present but not referenced by any CI configuration, which caps the score at 1

Cite as ARS-1.0-33

ARS-34

Eval coverage maps to destructive-action inventory

S · static

Pass

Every high-impact action class from ARS-08 has corresponding eval cases exercising both correct execution and correct refusal.

In production, this fails like this

Evals that only test the happy path certify that the agent works when nothing is wrong, which was never the question.

What the harness can and cannot establish

Static ceiling: 2 of 2. This is a set comparison between two documents in the repository: the destructive-action inventory and the eval cases. Both are readable in full, so the mapping is completely settled statically.

A pass means

A pass means every high-impact class in the ARS-08 inventory is referenced by at least one execution eval and one refusal eval. It is a coverage mapping, not a statement that the eval cases are adequate.

Signals

eval cases tagged or named with the action class they exercise
both an execution case and a refusal case per high-impact class
high-impact classes from ARS-08 with no eval case referencing them, reported by name
an ARS-08 inventory absent, which makes this check unscoreable and is reported as such rather than as a pass

Cite as ARS-1.0-34

ARS-35

Production behavior monitoring with drift detection

R · runtime

Pass

Task success rate, tool-call error rate, approval rejection rate, and cost per task are monitored in production with baselines and alerting on drift.

In production, this fails like this

Agent behavior drifts with data, usage patterns, and silent upstream changes. Point-in-time certification without monitoring expires immediately.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-35

ARS-36

Human feedback loop is instrumented

G · governance

Pass

Users can flag bad agent outputs in-flow; flags route to a triage process; triage outcomes feed the eval suite.

In production, this fails like this

Your users find the failure modes first. If there's no capture mechanism, that knowledge evaporates in Teams threads.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-36

ARS-37

Defined severity taxonomy and incident process for agent failures

G · governance

Pass

Agent-specific incident classes (wrong action taken, data exposure, injection event, cost runaway) are defined with severity levels, response owners, and postmortem requirements.

In production, this fails like this

The first agent incident handled ad hoc becomes the story leadership remembers. The process must predate the incident.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-37

Tier 8. Data Handling & Compliance

4 checks · weighted ×1 in the overall mean. Weighted at parity because the highest-severity data control, retrieval-layer access enforcement, is already carried at 1.5 by its dependence on Tier 1 identity propagation.

ARS-38

Data classification enforced at the retrieval layer

R · runtime

Pass

RAG/retrieval respects document-level and row-level access controls per requesting user; classification labels survive into the context and constrain what the agent may output.

In production, this fails like this

A vector store that indexed everything for everyone is an access-control bypass with cosine similarity.

Why this is not automatable

Runtime-testable. Requires access to a running system, its logs, and usually its non-production environment. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-38

ARS-39

PII/sensitive data minimization in context assembly

S · static

Pass

Context assembly redacts or excludes sensitive fields not required for the task; what enters the context window is a deliberate allowlist, not a table dump.

In production, this fails like this

Every field in the context is a field that can appear in the output, the logs, and the traces.

What the harness can and cannot establish

Static ceiling: 1 of 2. Whole-record interpolation into a prompt is a definite finding. An allowlist that is present but wrong reads identically to one that is right, because static analysis does not know which fields are sensitive in this domain.

A pass means

A pass means context assembly selects fields explicitly or applies a redaction step. It does not establish that the allowlist is correct or that every sensitive field is covered.

Signals

explicit field selection when building context from a record
a redaction or masking step applied before assembly
whole rows, whole documents or entire API responses serialised into the prompt
select-star queries feeding context assembly
a redaction function that exists but is not applied on the assembly path

Cite as ARS-1.0-39

ARS-40

Retention, deletion, and data-subject request handling covers agent artifacts

G · governance

Pass

Conversation logs, traces, embeddings, and memory stores are included in the organization's retention schedules and deletion workflows; a deletion request reaches all of them.

In production, this fails like this

"We deleted the record but it's still in the vector store and in 9,000 cached traces" is a compliance finding waiting for an auditor.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-40

ARS-41

Regulatory and review-board traceability package

G · governance

Pass

A maintained document maps each ARS control to its implementing mechanism, suitable for handing to legal, cybersecurity, or enterprise architecture review.

In production, this fails like this

Programs that can't produce this package re-litigate their existence at every review cycle. Programs that can, ship.

Why this is not automatable

Governance and process review. Requires interviews and document review. Assessed in a paid engagement, not by the harness.

Cite as ARS-1.0-41

Scoring model

Score	Label	Meaning
0	fail	No mechanism exists, or the mechanism present does not do what the pass criterion requires.
1	partial	A mechanism exists but is untested, unenforced, or enforced somewhere other than where it must be. A prompt instruction that asks the model to behave is always at most a 1.
2	pass with evidence	The mechanism exists, is enforced outside the model, and evidence of it was produced during the assessment.

Not evaluated is a state, not a score. A distinct state, not a score. Excluded from the numerator and the denominator. Reported by count so that no percentage is read as broader than it is.

Tier score is points awarded / points available, over the checks in that tier that were evaluated.

Overall score is Weighted mean of tier scores, using each tier's weight. Tiers 1, 2, 3 and 5 are weighted 1.5; tiers 4, 6, 7 and 8 are weighted 1.0.

Readiness bands

Band	Score	And	Reachable from static analysis alone
Production-Ready	85% and above	No check in tiers 1, 2 or 5 scored 0.	no
Conditional	65% and above	No check in tiers 1, 2 or 5 scored 0.	yes
Not Ready	below 65%	Also assigned regardless of score if any check in tiers 1, 2 or 5 scored 0.	yes

The static subset, and what it may claim

20 of the 41 checks carry the S flag and are read by the ars-check harness from a repository or config directory. The remaining 21 — 11 runtime and 10 governance — are not automatable and the harness does not attempt them.

Each static check declares its own ceiling: the highest score the harness may award it. Where static signals cannot tell a working mechanism from the appearance of one, the ceiling is 1 and the check says why. 13 of the 20 static checks are capped at 1, so the highest score a purely static run can reach is 27 of a possible 82 unweighted points across the full standard. The ceilings live in this document rather than in the harness, so the limit on what static analysis may claim is published rather than being implementation detail.

Conditional is the highest band a static run can reach. A static run leaves every runtime and governance check not_evaluated. Production-Ready asserts that controls are enforced and tested, and no static reader can establish either. The harness therefore cannot award Production-Ready at any score, and says so on every report.

Any published static score must state the number of checks evaluated, the number not evaluated, and that the result is a floor estimate rather than a certification.

A check that could not be evaluated is recorded as not_evaluated and is excluded from both the numerator and the denominator. It is never recorded as a zero and never as a pass. An instrument that fails in the flattering direction is worse than no instrument, because its output is indistinguishable from a real result.

A worked example: the harness run against a deliberately unsafe toy agent →

How a control is assessed

The 41 rows below are generated from the applicability methodology, a sidecar to this document rather than part of it. This standard is content-hashed and published; the methodology says, for each check, when it applies to a particular agent, what kind of evidence can settle it, and which categories of change invalidate evidence already gathered for it. Those are assessment decisions, they will change more often than the standard does, and putting them in the hashed document would mean re-hashing a published text every time a judgement moved.

This is a SIDECAR to ARS v1.0, not part of it. ARS v1.0 is content-hashed and published and is not modified by this document. What this adds is the three things an assessment needs and the standard deliberately does not carry: when each control applies to a given agent, what kind of evidence can settle it, and which categories of change invalidate evidence already gathered for it. Every applicability decision is made from named contract facts and states which ones. Nothing here certifies anything, and a control marked applicable is a control somebody still has to assess. ⚠️ v0.2 CHANGES ONE THING AND ADDS ONE. It makes invalidation conditional on the properties of the change rather than on its category alone — because adding a read-only internal lookup and adding a send-capable tool with a wildcard scope are the same category and different events, and a rule keyed on the category has to be written for the worse of the two. And it declares, per control, how fast that control's evidence goes stale, so `stale` becomes derivable rather than a word somebody types. v0.1 is preserved unchanged: an assessment made under it must remain readable under the rules it was made under.

Methodology v0.2 — written against ARS v1.0, content hash
12309637f0a716f9923204a4338c07acca5107a3cb9aa02b0a20b48902926d9c

A methodology that cites a version number rather than a hash is a methodology whose subject can move underneath it. The build refuses to render this page if the two hashes differ.

Applicability has three answers, not two

A predicate that could not be evaluated returns not evaluated — never false. If an erroring predicate evaluated as false the control would be marked not applicable and would drop out of the denominator, so a failure of the instrument would read as a smaller, cleaner scope. Not applicable is excluded from both the numerator and the denominator; not evaluated stays visible and is excluded from neither, because establishing nothing must not shrink the applicable set.

Attestation alone settles 1 of the 41 checks. For the other 40, an owner's statement that the mechanism works is the claim under test, so it cannot also be the evidence for it. 15 hard blockers are declared across the 41 checks: a hard blocker is a declared fact that no score elsewhere can offset.

Invalidation is conditional on what the change actually was

Methodology v0.2 changed this, and it is the change a client argues with least once they have seen it. In v0.1 every invalidation rule was keyed on the change's category alone, so tool_added fired the same way for a read-only internal lookup and for a send-capable tool holding a wildcard scope in production. Those are the same category and different events, and a rule written for the second has to be applied to the first.

14 of the rules below now carry a condition over the change's own properties — its side effect, whether it can transmit outward, how broad its scope is, which environments it reaches — and each one states why. A control whose evidence genuinely stops describing the system whatever the new tool does keeps an unconditional rule and says so.

⚠️ A condition that cannot be evaluated invalidates. If the declaration does not carry the fact a rule needs, the evidence is treated as no longer describing the system. The alternative — sparing evidence whenever the instrument cannot tell — is the direction that produces a flattering answer, and it is the one thing this methodology will not do.

When each check applies, and what can settle it

Check	Applies when	Evidence that can settle it	Static ceiling	Invalidated by	Goes stale after
ARS-01	at least one declared tool authenticates by `api_key` or `service_account` or `delegated_user` or `workload_identity_federation` or `oauth_client_credentials` or `oauth_authorization_code` or `unspecified`	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	4 change categories 1 of them conditional on the change	90 days runtime observation
ARS-02	at least one declared tool authenticates by `api_key` or `service_account` or `delegated_user` or `workload_identity_federation` or `oauth_client_credentials` or `oauth_authorization_code` or `unspecified`	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	5 change categories 1 of them conditional on the change	180 days static reading
ARS-03	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	2 of 2	2 change categories	180 days static reading
ARS-04	at least one declared tool authenticates by `api_key` or `service_account` or `delegated_user` or `workload_identity_federation` or `oauth_client_credentials` or `oauth_authorization_code` or `unspecified`, or the declared trigger modes include `scheduled` or `event_driven` or `agent_initiated`	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	4 change categories 1 of them conditional on the change	180 days static reading
ARS-05	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	2 change categories	90 days runtime observation
ARS-06	the contract declares at least `1` tool(s)	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	2 change categories	180 days static reading
ARS-07	the contract declares at least `1` tool(s)	automatically verified, manually verified attestation alone cannot settle it	2 of 2	3 change categories	180 days static reading
ARS-08	at least one declared tool creates, modifies, deletes, sends or spends, or at least one declared skill has side effect `write` or `send` or `spend` or `delete`	automatically verified, manually verified attestation alone cannot settle it	2 of 2	5 change categories 1 of them conditional on the change	180 days static reading
ARS-09	at least one destructive-action inventory entry is classified `irreversible` or `reversible_with_effort`, or at least one declared tool has side effect `send` or `spend` or `delete`	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	6 change categories 1 of them conditional on the change	180 days static reading
ARS-10	the contract declares at least one approval class, or at least one declared tool is gated at `human_approval` or `human_approval_conditional`	manually verified, attested attestation alone cannot settle it	G not read by the harness	6 change categories 1 of them conditional on the change	365 days governance review
ARS-11	the contract declares at least `1` tool(s)	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	5 change categories	90 days runtime observation
ARS-12	the contract declares at least `2` tool(s), and at least one declared tool can carry content out of the trust boundary, or at least one declared data sink is outside the platform, or at least one declared tool has side effect `write` or `send` or `spend` or `delete`	manually verified, attested attestation alone cannot settle it	G not read by the harness	6 change categories	365 days governance review
ARS-13	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	2 change categories	90 days runtime observation
ARS-14	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	4 change categories	180 days static reading
ARS-15	a declared sink or skill carries data classified `internal` or `confidential` or `personal_data` or `special_category` or `financial` or `credential`, or at least one declared prompt interpolates user or external content	manually verified, attested attestation alone cannot settle it	G not read by the harness	5 change categories	365 days governance review
ARS-16	the declared lifecycle state is `pilot` or `production`, or the declared criticality is `moderate` or higher	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	6 change categories	90 days runtime observation
ARS-17	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	2 of 2	2 change categories	180 days static reading
ARS-18	at least one declared tool creates, modifies, deletes, sends or spends, or the declared autonomy level is `human_on_the_loop` or higher, or the declared trigger modes include `scheduled` or `event_driven` or `agent_initiated`, or the declared maximum plausible blast radius reaches `single_tenant` or wider	automatically verified, manually verified attestation alone cannot settle it	R not read by the harness	5 change categories 1 of them conditional on the change	90 days runtime observation
ARS-19	at least one declared tool creates, modifies, deletes, sends or spends, or at least one declared skill has side effect `write` or `send` or `spend` or `delete`	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	4 change categories 1 of them conditional on the change	180 days static reading
ARS-20	the contract declares at least `1` tool(s), or the declared autonomy level is `human_on_the_loop` or higher	automatically verified, manually verified attestation alone cannot settle it	1 of 2 — capped	5 change categories	180 days static reading
ARS-21	the declared lifecycle state is `pilot` or `production`, and the declared criticality is `moderate` or higher, or the declared maximum plausible blast radius reaches `single_customer` or wider, or at least one declared tool creates, modifies, deletes, sends or spends	manually verified, attested attestation alone cannot settle it	G not read by the harness	6 change categories	365 days governance review
ARS-22	at least one declared tool creates, modifies, deletes, sends or spends, or at least one declared skill has side effect `write` or `send` or `spend` or `delete`, or at least one destructive-action inventory entry is classified `reversible` or `reversible_with_effort` or `irreversible`	automatically verified, manually verified, attested attestation alone cannot settle it	R not read by the harness	7 change categories 1 of them conditional on the change	90 days runtime observation
ARS-23	every agent in the envelope — this control has no condition	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	4 change categories	180 days static reading
ARS-24	at least one declared prompt is whose trust level is `assembled_untrusted`, or at least one declared prompt interpolates user or external content, or at least one declared data sink is outside the platform, whose direction is `inbound` or `bidirectional`	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	5 change categories	180 days static reading
ARS-25	at least one declared prompt interpolates user or external content, or at least one declared data sink is outside the platform, and at least one declared tool creates, modifies, deletes, sends or spends, or at least one declared tool can carry content out of the trust boundary, or a required scope anywhere in the declaration is a wildcard or a breadth-named scope (`*`, `admin`, `write_all` and the like), or a declared sink or skill carries data classified `confidential` or `personal_data` or `special_category` or `financial` or `credential`	automatically verified, manually verified, attested attestation alone cannot settle it	R not read by the harness	9 change categories	90 days runtime observation
ARS-26	at least one declared tool can carry content out of the trust boundary, or at least one declared data sink is outside the platform, or at least one declared skill has side effect `send` or `write`	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	5 change categories 1 of them conditional on the change	180 days static reading
ARS-27	at least one declared data sink is outside the platform, or at least one declared tool can carry content out of the trust boundary, or a declared data sink permits `` as a destination, or at least one declared skill has side effect `send`, and* a declared sink or skill carries data classified `internal` or `confidential` or `personal_data` or `special_category` or `financial` or `credential`	manually verified, attested attestation alone cannot settle it	G not read by the harness	7 change categories 1 of them conditional on the change	365 days governance review
ARS-28	every agent in the envelope — this control has no condition	automatically verified, manually verified attestation alone cannot settle it	2 of 2	3 change categories	180 days static reading
ARS-29	the declared maximum plausible blast radius reaches `single_tenant` or wider, or at least one declared tool acts as `shared_service_account` or `service_identity` or `unspecified`, or a required scope anywhere in the declaration is a wildcard or a breadth-named scope (`*`, `admin`, `write_all` and the like)	automatically verified, manually verified, attested attestation alone cannot settle it	R not read by the harness	5 change categories 1 of them conditional on the change	90 days runtime observation
ARS-30	the declared lifecycle state is `pilot` or `production`, or the declared autonomy level is `human_on_the_loop` or higher, or the declared trigger modes include `scheduled` or `event_driven` or `agent_initiated`	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	5 change categories	180 days static reading
ARS-31	the declared lifecycle state is `pilot` or `production`, and the declared criticality is `moderate` or higher, or the declared trigger modes include `scheduled` or `event_driven` or `agent_initiated`, or the declared autonomy level is `human_on_the_loop` or higher	automatically verified, manually verified, attested attestation alone cannot settle it	G not read by the harness	5 change categories	365 days governance review
ARS-32	the contract declares at least `1` tool(s), and the declared autonomy level is `human_on_the_loop` or higher, or the declared trigger modes include `scheduled` or `event_driven` or `agent_initiated`, or no value is declared for the containment field `loop_ceiling`, or no value is declared for the containment field `retry_ceiling`	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	7 change categories	180 days static reading
ARS-33	the declared lifecycle state is `pilot` or `production`	automatically verified, manually verified attestation alone cannot settle it	2 of 2	6 change categories	180 days static reading
ARS-34	at least one destructive-action inventory entry is classified `reversible` or `reversible_with_effort` or `irreversible`	automatically verified, manually verified attestation alone cannot settle it	2 of 2	6 change categories 1 of them conditional on the change	180 days static reading
ARS-35	the declared lifecycle state is `production`	automatically verified, manually verified, attested attestation alone cannot settle it	R not read by the harness	7 change categories	90 days runtime observation
ARS-36	the declared lifecycle state is `pilot` or `production`, and the declared trigger modes include `human_initiated`, or at least one declared data sink is outside the platform, or at least one declared tool can carry content out of the trust boundary, or at least one declared skill has side effect `send`	manually verified, attested attestation alone cannot settle it	G not read by the harness	4 change categories	365 days governance review
ARS-37	the declared lifecycle state is `pilot` or `production`, and at least one declared tool creates, modifies, deletes, sends or spends, or at least one declared data sink is outside the platform, or the declared maximum plausible blast radius reaches `single_customer` or wider, or a declared sink or skill carries data classified `confidential` or `personal_data` or `special_category` or `financial` or `credential`	manually verified, attested	G not read by the harness	7 change categories	365 days attestable
ARS-38	at least one declared tool has side effect `read`, or at least one declared skill has side effect `read`, and a declared sink or skill carries data classified `internal` or `confidential` or `personal_data` or `special_category` or `financial` or `credential`	automatically verified, manually verified, attested attestation alone cannot settle it	R not read by the harness	5 change categories 1 of them conditional on the change	90 days runtime observation
ARS-39	the contract declares at least one prompt, and a declared sink or skill carries data classified `confidential` or `personal_data` or `special_category` or `financial` or `credential`	automatically verified, manually verified, attested attestation alone cannot settle it	1 of 2 — capped	6 change categories	180 days static reading
ARS-40	the declared lifecycle state is `pilot` or `production`, and a declared sink or skill carries data classified `confidential` or `personal_data` or `special_category` or `financial` or `credential`	automatically verified, manually verified, attested attestation alone cannot settle it	G not read by the harness	4 change categories	365 days governance review
ARS-41	the declared lifecycle state is `production`, or the declared criticality is `high` or higher, or the declared maximum plausible blast radius reaches `single_tenant` or wider, or a declared sink or skill carries data classified `personal_data` or `special_category` or `financial` or `credential`	manually verified, attested attestation alone cannot settle it	G not read by the harness	6 change categories	365 days governance review

How fast each control's evidence goes stale

A control's window comes from a published class rule, not from 41 individual numbers — so a reader can disagree with the rule, which is one argument, rather than with 41 judgements, which is none. `restart_on` is DERIVED from the control's own invalidating-change list: the set of changes that void its evidence is the set of changes that void its evidence, and writing it twice would create two lists that can disagree.

Class	Window	Applies when	Why that number
`runtime_observation`	90 days	the control carries the [R] runtime flag in the standard	Evidence that a mechanism WORKED is evidence about a running system on the day it was observed. Three months is roughly a quarter of releases for a team shipping weekly, and beyond that the observation describes a system that has been rebuilt around it.
`static_reading`	180 days	the control carries the [S] static flag	A static reading is a fact about code and configuration, and it holds for as long as they do. It is given twice the runtime window because the changes that would void it are the ones `restart_on` already catches — age is the backstop here, not the primary control.
`governance_review`	365 days	the control carries the [G] governance flag	A policy, an approval process or a retention rule is re-affirmed on an annual cycle in every organisation that has one. A shorter window would manufacture staleness that no reviewer would recognise.
`attestable`	365 days	attestation alone can settle the control, whatever its flag	An attestation is a statement of intent by an accountable party, and intent is re-stated annually rather than continuously. ⚠️ This is the LONGEST window and the WEAKEST evidence, which is uncomfortable and is correct: freshness is about when a claim stops describing the system, not about how much the claim is worth. The kind is recorded separately on every item, and nothing here upgrades an attestation.

A control's clock also restarts on any change that invalidates its evidence, whatever the age — evidence gathered yesterday against a prompt that changed today is not fresh, it is void. That list is derived from the control's own invalidation rules rather than written twice.

The risk profile the applicability decisions are made against

7 dimensions, each read from named fields of the declaration. There is no aggregate number: a single risk score would be the one thing on this page a reader could not argue with, and every decision below names the fields that produced it.

authority surface

What can this agent do to the world, at the widest point of its declared tool set?

Level	When it is reached	What that means
`read_only`	every agent in the envelope — this control has no condition	No declared tool creates, modifies, deletes, sends or spends. The floor, and the only level that needs no condition.
`writes`	at least one declared tool whose side effect is `write`	At least one tool creates or modifies records. Reversible in principle, and a compensating action has to exist.
`transmits`	at least one declared tool whose side effect is `send`	At least one tool sends. What is sent cannot be unsent, and the recipient is outside the system that produced it.
`spends_or_destroys`	at least one declared tool whose side effect is `spend` or `delete`	At least one tool moves money or destroys records. Both are irreversible in the sense that matters to a review board: there is no undo, only a compensating action somebody has to perform.

transmission reach

How far outside the trust boundary can content this agent handles travel?

Level	When it is reached	What that means
`contained`	every agent in the envelope — this control has no condition	No declared sink is external and no tool declares outbound transmission. Nothing this agent touches has a declared route out.
`internal_only`	at least one declared data sink is inside the platform, whose direction is `outbound` or `bidirectional`	Data moves, and every declared destination is inside the platform.
`named_external`	at least one declared data sink is outside the platform, or at least one declared tool can carry content out of the trust boundary	At least one declared destination is outside the platform, and the contract names it. A named external destination is reviewable.
`unrestricted_external`	at least one declared data sink is outside the platform, permitting any destination	An external sink permits every destination. A wildcard makes every destination permitted and no destination reviewed, which is a different kind of claim from a long list.

data sensitivity

What is the most sensitive class of data the declaration says this agent handles?

Level	When it is reached	What that means
`public`	every agent in the envelope — this control has no condition	Nothing above public is declared by any sink or skill.
`internal`	a declared sink or skill carries data classified `internal`	Internal material is in scope. Disclosure is a business problem rather than a personal one, and the controls that matter are about the boundary rather than about the subject.
`confidential_or_personal`	a declared sink or skill carries data classified `confidential` or `personal_data` or `financial`	Personal, financial or confidential material is in scope, so a disclosure has a subject who can be harmed by it and usually a regulator who has an opinion about it.
`special_category_or_credential`	a declared sink or skill carries data classified `special_category` or `credential`	Special-category personal data or credentials are in scope. A single disclosure here is not recoverable by apology, and a credential disclosure widens every other control's blast radius at once.

delegated authority

Whose authority do the downstream calls actually carry?

Level	When it is reached	What that means
`end_user`	every agent in the envelope — this control has no condition	Every declared tool acts as the calling user, so downstream authorisation is evaluated against the person who asked.
`mixed`	at least one declared tool acting as `service_identity` or `unspecified`	At least one tool acts as a service identity or does not say. Some part of what this agent does is not attributable to a person at the point it happens.
`shared_identity`	at least one declared tool acting as `shared_service_account`	At least one tool acts as a shared service account. Any user can reach anything that account can reach, which is the single most common finding in enterprise agent deployments.

autonomous triggering

Can this agent act without a person asking it to, and how much of the loop is a person in?

Level	When it is reached	What that means
`human_initiated`	every agent in the envelope — this control has no condition	A person starts every run and every control that assumes a human is present at the start holds.
`scheduled_or_event`	the declared trigger modes include `scheduled` or `event_driven`	A schedule or an event can start a run. Nobody is necessarily watching when it does.
`agent_initiated`	the declared trigger modes include `agent_initiated`, or the declared autonomy level is `autonomous` or higher	The agent can start its own work, or acts at full autonomy. There is no point in the loop where a person is structurally required.

blast radius

How far does the worst plausible outcome of one bad run reach?

Level	When it is reached	What that means
`single_record`	every agent in the envelope — this control has no condition	The declaration bounds a run to one record.
`single_customer`	the declared maximum plausible blast radius reaches `single_customer` or wider	One customer's data or money is reachable in one run.
`single_tenant`	the declared maximum plausible blast radius reaches `single_tenant` or wider	A whole tenant is reachable, so isolation between tenants becomes load-bearing.
`all_customers`	the declared maximum plausible blast radius reaches `all_customers` or wider	Every customer is reachable from one run. At this level a single prompt injection is an incident rather than a ticket.
`external_third_parties`	the declared maximum plausible blast radius reaches `external_third_parties` or wider	The declared reach extends to parties outside the organisation entirely, who did not choose to be in scope.

containment declared

How much of what stops a runaway run is written down rather than left to the runtime?

Level	When it is reached	What that means
`fully_bounded`	every agent in the envelope — this control has no condition	Every containment field carries a declared value. The floor here is the GOOD state, deliberately: this dimension measures what is missing.
`partially_bounded`	no value is declared for the containment field `retry_ceiling`, or no value is declared for the containment field `loop_ceiling`, or no value is declared for the containment field `default_timeout_ms`, or no value is declared for the containment field `session_budget.max_cost_usd`	At least one ceiling is undeclared. An undeclared ceiling is not a ceiling of zero; it is whatever the runtime happens to impose, which nobody reviewed.
`unbounded`	no value is declared for the containment field `retry_ceiling`, and no value is declared for the containment field `loop_ceiling`, and no value is declared for the containment field `session_budget.max_cost_usd`, and no value is declared for the containment field `session_budget.max_tokens`	Neither ceiling, neither budget. Nothing in the declaration says what stops a run that goes wrong.

This document, in use

A standard nobody has applied is a rubric. These are the instruments built against this text, and each ships the whole input it was computed from so a reader can recompute it and disagree with the result.

A scored assessment — the static harness against a deliberately unsafe toy agent, every finding with its file and line.
A change-impact analysis — one agent, two versions: which evidence, tests and approvals the change invalidated, which survived, and whether it can ship.
A declaration that did not match the code — a contract describing a read-only tool set, and a send-capable tool found in TypeScript source. Verdict: BLOCK.
Evidence produced rather than asserted — seven of these checks probed against two configurations of one reference agent, with what each run does and does not establish.
The assessment offer — what an engagement against this standard covers, and what it does not.

Changelog

v1.0 · 2026-08-05 · draft

First authored version. 41 checks across 8 tiers: 20 statically checkable, 11 runtime-testable, 10 governance review. Nothing has been assessed against a real production system by a second party.

Check	Change	Why
ARS-01	added	Identity propagation is the first question every enterprise security review board asks about an agent deployment, and a shared service identity is the most common finding. It anchors Tier 1.
ARS-07	added	Tool schema permissiveness is the only control in the set that a static reader can settle completely: the schema either constrains the domain or it does not. Published with a static ceiling of 2 for that reason, and it is the check the harness can be most confident about.
ARS-09	added	Approval gating is published as statically checkable at a ceiling of 1 rather than 2, because static analysis can find an approval mechanism but cannot establish that execution is impossible without it. The distinction between a structural gate and a prompt instruction is exactly what the ceiling exists to preserve.
ARS-10	added	Approval fatigue is published as a governance check rather than dropped, because a gate that fires 400 times a day is measurably worse than no gate, and no code inspection can see approval volume.
ARS-24	added	Untrusted-content segregation is stated as a trust-boundary property of the architecture rather than as a model behaviour, because writing it as a model property would make it unassessable and would imply it is the vendor's to fix.
ARS-41	added	The traceability package is a control rather than an appendix. Programs that cannot produce it re-litigate their existence at every review cycle, which is a readiness failure with no technical cause.

A MAJOR version bump means an assessment result under the old version is not comparable to one under the new. Every published version keeps its own address and its own hash, so a citation written today resolves to the text it was written against.