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 gate, verdicts, kill switch)
Decision governance (declared intent, deferral, approval lineage)
AVAR evidence (signing, chaining, offline verification)
Local-first enforcement and evidence portability
Optional evidence relay transport behavior

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

Every agent-initiated action routes through the policy gate before dispatch. Adapters (@aarmos/adapter-mcp, adapter-openapi, adapter-deeplink, adapter-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

Five authorization decisions

The gate produces ALLOW | DENY | MODIFY | STEP_UP | DEFER. MODIFY carries argsBeforeHash + argsAfterHash + modifyReasons. DEFER carries deferralId + deferReason + resolutionMethods + timeoutMs; resolution emits a follow-up decision referencing the same deferralId. STEP_UP and DEFER timeouts fall through to DENY, never ALLOW. A DENY may carry policy-authored alternatives — statements of a narrower path already written down, never a runtime-synthesized grant.

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. Ed25519 signatures verify offline via @avar-standard/verify or the standalone avar binary; altering any field fails verification. Chain closure markers are specified in SPEC-ADDENDUM-1.11 and checked by verifyClosure.

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 Planned

Semantic distance tracking

Intent embedding + drift threshold is on the roadmap. Trigger: ≥1,000 real runs to calibrate false-positive rate, or a paying customer requirement. Deliberately parked.

R8SHOULD Partial

Telemetry export

SIEM sinks ship on Team — Splunk HEC, Datadog Logs, generic webhook, syslog, capped at one destination per workspace. Enterprise removes the cap and adds routing. OpenTelemetry sink is planned when the first enterprise pilot asks. Event shape and starter detections 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.

D2MUST Meets

Evidence transport is content-preserving

When the optional evidence relay is enabled (Team/Enterprise aggregation), stored bytes equal signed bytes. The relay carries governance evidence, never execution state. Typed core sections are validated; unknown core sections are rejected, unknown namespaced extensions are accepted. Conformance tests are published in the public Aarmatix/avar repository (packages/conformance/RELAY.md).

D3MUST Meets

Evidence portability

Evidence exports verify offline with no Aarmos component present, using @avar-standard/verify or the avar binary. Round-trip portability is covered by an automated guardrail suite.

D4SHOULD Partial

Customer-hosted relay (BYOS)

Bring-your-own-storage is available for Enterprise deployments; the hosted relay remains the Team default. Fully customer-operated relay packaging is in progress.

D5SHOULD Planned

Machine-readable conformance (conformance.json)

This statement is human-readable today. A machine-readable endpoint is architected for but not published; do not build automation against this page yet.

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)	Planned	Not yet submitted.
Production deployment (≥5 customers, ≥3 months)	Planned	GTM-gated; pre-launch.
Security certification (SOC 2 II / ISO 27001 / FedRAMP)	Planned	SOC 2 CC7.2 is the pilot anchor; certification is post-revenue.
Independent third-party assessment	Planned	None performed. This document is self-attested.
Benchmarking commitment	Meets	Latency benchmarks published; willing to participate.

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 released version of @avar-standard/verify or the avar binary.

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

Specification: AVAR spec · Actions & resources
Verifier: npm i @avar-standard/verify or brew install aarmatix/tap/avar
Conformance fixtures and transport tests: public Aarmatix/avar (packages/conformance)
Walk the loop offline: aarmos demo · aarmos test policies/tests · avar verify .aarmos/avar/receipt-*.json
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).