Reference

Self-Attested Conformance Statement

Record, verify, replay — what a receipt contains, how it is sealed, and how you confirm nothing was altered afterwards.

Product	Aarmos Governance Runtime
Specification	AARM Conformance Requirements · AVAR 1.0 (Normative)
Statement version	1.2
Assessment date	2026-08-06
Assessment method	Self-attestation, supported by the automated guardrail and conformance test suites. No independent assessor has reviewed this.

This is a technical statement, not a claim of certification. It records what Aarmos conforms to, how that was assessed, and what is intentionally out of scope. Nothing here is “certified”, “verified”, or “compliant” in the third-party sense. Requirements that are unmet are listed as unmet.

Scope

Included

Runtime governance (policy evaluation, gate outcomes, kill switch)
Consequence governance (declared intent, deferral, approval lineage)
AVAR evidence (signing, chaining, offline verification)
Local-first enforcement and evidence portability

Excluded

Preview and experimental features
Unreleased participants and unpublished SDKs
Customer-written policies and participants
Third-party implementations of the specification
Anything under an active publication hold

Specification conformance — Core (MUST)

Did we build the specification?

R1MUST Meets

Pre-execution interception

Agent actions on supported adapter and proxy paths route through the policy gate before dispatch. Adapters (MCP, OpenAPI, deep-link, A2A and LLM adapters) call the gate synchronously; the local hostname-only proxy catches escape-hatch HTTPS. Gate unavailability = deny (no fail-open). Kill-switch scopes (all | writes | destructive) short-circuit before dispatch. Coverage is connector egress only — traffic that never passes an adapter or the proxy is out of scope (see Known exclusions).

decisionsourcegates[]killSwitchAtkillScope

R2MUST Meets

Context accumulation

Run context threads prior tool calls, arguments (redacted), outputs, delegation chain, and data classifications into each subsequent evaluation. Receipts are hash-chained per-step (prevStepHash / stepHash) and per-entry (prevHash / entryHash), so tampering with prior context is detected by the offline verifier.

prevStepHashstepHashprevHashentryHashdelegationChain[]

R3MUST Meets

Policy evaluation with declared intent

The 8×8 access matrix plus ABAC vocabulary evaluate action + context (data classification, environment, risk, custom attributes). Intent is declared on run start (aarmos run --intent "…"), threaded into contract evaluation as ctx.intent and stamped as intent + intentHash. Intent is a declared input, not an inferred one: Aarmos records what was declared and evaluates against it, it does not judge whether the declaration was truthful.

intentintentHashpolicyFingerprintcontract.incontract.out

R4MUST Meets

Specification gate-result encoding

This row reports legacy AARM wire vocabulary required by the assessed specification: ALLOW | DENY | MODIFY | STEP_UP | DEFER. It does not define current Aarmos canonical Decision semantics. In the current Aarmos model, policy returns allow | deny | step_up | defer for a proposed Consequence; any argument transformation described by the specification's MODIFY value is recorded separately with argsBeforeHash, argsAfterHash, and modifyReasons. DEFER retains deferralId, deferReason, resolutionMethods, and timeoutMs. STEP_UP and DEFER timeouts fail closed to DENY.

decisionargsBeforeHashargsAfterHashmodifyReasons[]deferralIddeferReasonresolutionMethods[]timeoutMsresolvedAtresolutionMethodalternatives[]

R5MUST Meets

Tamper-evident receipts

Receipts follow AVAR 1.0 (Normative) and include decision, timestamp, requester context, delegation chain, and policy fingerprint. Exported receipt integrity can be checked with the browser verifier or public verification library; the standalone avar binary is not publicly distributed. Signature attribution requires a separately trusted issuer key. Chain checks apply to the exported evidence, not events absent from the export.

signaturedevicePubKeypolicyFingerprintentryHashstepHash

R6MUST Meets

Identity binding

Every receipt is bound to agentId + devicePubKey; delegation chains preserve principal identity across nested calls (attenuation rule). Origin stamping adds release + releaseSig + builderPubkey. DEFER → resume preserves the original identity in the resolution receipt.

agentIddevicePubKeydeviceFingerprintdelegationChain[]origin

Specification conformance — Extended (SHOULD)

R7SHOULD Not supported

Semantic distance tracking

Not implemented in the current release.

R8SHOULD Partial

Telemetry export

Signed receipts can be forwarded from the local runtime to a customer-controlled S3, GCS, R2, or custom HTTPS endpoint. OpenTelemetry export is not currently available. Plan availability is described on /pricing. Event shape and starter detections are documented at /docs/integrations/siem.

R9SHOULD Meets

Least privilege enforcement

Scoped tool invites, capability tiers, and the Write/Delete ⇒ Read implication in the 8-verb model. Read-only credentials cannot perform writes; delegation attenuation prevents privilege escalation across nested runs.

Deployment conformance

Is a given deployment configured the way the specification assumes?

Deployment conformance is intentionally shorter than specification conformance. It covers only properties that genuinely vary between deployments. All other guarantees are implementation properties established by specification conformance above.

D1MUST Meets

Local-first enforcement

Policy evaluation, receipt signing, and key custody run on the operator's device and never require our cloud. A workspace can be operated with no Aarmos-hosted component in the enforcement path.

D3MUST Meets

Evidence portability

Evidence exports can be checked independently with the public verification library or browser verifier. The standalone avar binary is not publicly distributed. Round-trip portability is covered by an automated guardrail suite; verification does not establish complete event capture or downstream success.

D4SHOULD Partial

Customer-controlled evidence storage (BYOS)

A customer-controlled storage endpoint is available for supported deployments. A fully customer-operated relay runtime is not currently available.

D5SHOULD Not supported

Machine-readable conformance (conformance.json)

This statement is human-readable only. No machine-readable endpoint is published; do not build automation against this page.

Local proxy conformance

Where the local runtime binds, and who may talk to it. See the security model for the full threat statement, including what is not protected.

LP-1MUST Meets

Default bind is loopback

Every listener resolves its bind address through a single endpoint module whose default is 127.0.0.1. Classification is semantic (::1 is loopback, :: is wildcard), and a guardrail suite asserts the default and the classification table.

LP-2MUST Meets

Exposure class is recorded on listener start

Listener starts and refused binds append a hash-chained runtime lifecycle event carrying the literal address and the exposure class (loopback / local-ipc / network). The chain is bootstrap-safe: it does not route through decision execution, so runtime start never depends on the runtime already running.

LP-3MUST Meets

Non-loopback exposure requires configured network authentication

No network-authentication mode is configured, so a non-loopback listen address is refused with a non-zero exit and a recorded refusal event. There is no confirmation flag that overrides this.

LP-4MUST Meets

Local credentials never appear in diagnostics

Posture output (aarmos doctor) reports transport, bind, exposure, authentication mode, TLS, and remote-access state without credential values; only a non-secret session id is shown. Session state is redacted before it enters JSON output or evidence, credentials are never passed through argv, and a guardrail asserts both.

LP-5MUST Meets

Every local connection is authenticated, on every transport

Authentication is applied above the transport layer, so loopback TCP and Unix socket / named pipe connections are verified identically. The default mode is required; the compatibility mode is explicit opt-in and never the default.

LP-6MUST Meets

Session credentials have a bounded lifecycle

A session credential is minted when a listener starts, rotating any prior value so a credential from a dead listener cannot authenticate against a new session, and revoked when the listener stops. Short-lived listeners mint a non-persisted session.

LP-7SHOULD Partial

OS-level isolation is available where the platform supports it

A Unix domain socket / Windows named pipe transport is selectable and carries the same authentication model. It is not yet the default for first-party clients, and OS peer-credential pinning is not implemented. Neither mechanism is described as defending against a process running as the same OS user.

Organizational requirements

Condition	Status	Note
Evaluation engagement (TWG)	Not supported	Not submitted.
Production deployment evidence	Not supported	Not claimed in this statement.
Independent security attestations and certifications	Not supported	A SOC 2 attestation is not currently available.
Independent third-party assessment	Not supported	None performed. This document is self-attested.
Benchmarking commitment	Partial	Willing to participate in shared benchmarking.

Operational assumptions

These are environmental and operational prerequisites, not conformance requirements. The guarantees above hold only when:

Agent traffic is routed through an Aarmos adapter or the local hostname-only proxy. Traffic that bypasses both is not governed and produces no evidence.
The operator authors governance policy correctly. Aarmos enforces declared policy; it does not decide what policy ought to be.
Endpoint security, device custody, and identity providers remain under the customer's control and are not compromised.
Signing keys and local vaults remain uncompromised.
Clocks on the executing device are broadly accurate; receipts record device time.
Third-party systems return truthful results and honor the trust boundaries the customer assigns to them.
Verifiers use a compatible verification implementation and a separately trusted issuer key when attribution is required. The standalone avar binary is not publicly distributed.

Known exclusions (not evaluated)

Correctness of customer-authored policies, rules, or participants.
Correctness or completeness of business policy, legal obligations, or regulatory interpretation.
Quality of human approval decisions in STEP_UP or DEFER flows.
Model behavior, output quality, or hallucination of the underlying LLM.
Payload inspection of TLS traffic. The proxy is hostname-only by design (ADR-0001); rich evidence comes from adapters.
Preview or experimental features, unreleased participants, and unpublished SDKs.
Any conformance claim about third-party implementations of the specification.

Evidence

The CLI is not publicly distributed. Commands on this page are reference examples, not instructions you can run today.

Specification: AVAR overview · Actions & resources
Verifier: in-browser verifier · @avar-standard/verify (public npm)
Conformance fixtures and transport tests: not currently publicly published.
Walk the loop offline: aarmos demo · aarmos test policies/tests
Responsibility split: Shared responsibility · Governance guarantees · Trust · Privacy

Version history

Version	Date	Changes	Assessment
1.2	2026-08-06	Restructured as a conformance statement: scope, operational assumptions, known exclusions, version history. Split specification conformance from deployment conformance. Added D1–D5 and explicit framing that deployment conformance is intentionally narrower.	Self-attestation + automated guardrail suite
1.1	2026-08-04	Reviewed against AVAR 1.0 (Normative). Added chain-closure and alternatives evidence.	Self-attestation
1.0	2026-07-16	Initial requirement matrix for Core (R1–R6) and Extended (R7–R9).	Self-attestation

Aarmos has not been assessed against AARM by an independent party. This page is a self-attestation against the public conformance requirements at aarm.dev/conformance, updated as the specification and implementation evolve. Last reviewed 2026-08-06 against AVAR 1.0 (Normative).