Aarmos
Implements the documented runtime behavior, reports known scope and uncertainty, and produces evidence for governed consequential actions.
Trust · Shared responsibility
Trust through explicit boundaries.
Aarmos is responsible for the behavior it implements and the evidence it produces. Customers control governance intent, deployment, credentials, and the trust root they supply. Providers and target systems control what happens beyond their own boundaries.
This page explains why reliance on Aarmos is justified and where that reliance ends. It is maintained by Aarmos and is not an independent audit, certification, or legal opinion.
Three parties
Trust is shared, not transferred.
Customer
Defines governance intent and authority, configures supported paths, controls credentials and trust roots, and determines acceptable use.
Target or provider
Receives dispatched requests and controls service behavior, availability, data handling, and outcomes beyond the Aarmos boundary.
The detailed allocation, including the artifact that records each contribution, remains in the shared responsibility model.
Inherited product truth
One governed lifecycle. Three distinct owners.
Trust does not redefine authorization, execution, or verification. Their canonical pages own those meanings and limits.
Local and hosted
Where responsibility and data cross.
Governance is local-first. The website, account and team administration, entitlements, optional evidence services, and configured external services remain distinct dependencies.
- Governance coreCustomer infrastructure
- Policy evaluation, receipt signing, and key custody do not require an Aarmos-hosted service.
- Account and administrationAarmos-hosted
- Account, entitlement, team membership, identity administration, and static app delivery use hosted services.
- Evidence servicesOptional and deployment-dependent
- Evidence starts locally. A workspace may configure delivery to customer-controlled storage. An opt-in Aarmos-hosted evidence relay is designed but not currently enabled; Aarmos does not currently store customer evidence, and automatic Aarmos-hosted forwarding is not supported.
- Customer-selected servicesProvider or target
- Configured AI providers, connectors, APIs, and evidence destinations receive only the traffic the customer directs to them.
Optional product analytics and command-line telemetry are opt-in. AI Assist sends a drafting request and minimised context only when invoked. The privacy disclosure is the authoritative category-level account of data handling.
Organization trust root
Supplied by the customer. Used by Aarmos.
An operator supplies and pins the organization’s public trust root after checking it through an independent channel. Aarmos verifies organization records against that configured root; it does not establish the root’s provenance or control its custody.
Current limitation
Replacement, rotation, revocation, organization PKI integration, directory integration, and hardware custody for this trust root are not current capabilities. No lifecycle claim is made beyond verification against the supplied root.
Trust properties
Properties you can inspect, with limits attached.
Local governance authority
The runtime evaluates policy, signs receipts, and holds governance keys on customer infrastructure. Hosted administration remains a separate dependency.
Local-first boundary →Portable evidence
Evidence is append-only, signed, and hash-chained: tamper-evident, not tamper-resistant. The standalone command-line verifier is not currently publicly distributed; the browser verifier and public verifier library are available today.
Verification meaning →Explicit enforcement scope
Enforcement is path-specific. An enforcing path does not establish that every route to the same consequence is known or governed.
Run boundary truth →Bounded security claims
Security architecture reduces named risks within its stated boundary. It is not a certification or a promise that the surrounding system is secure.
Security model →Verification establishes artifact integrity and that the artifact’s signatures validate against the supplied trust root. It does not establish path enforcement, an unavailable Effect, a business Outcome, safety, or compliance.
Optional AI Assist
AI drafts. It cannot activate governance.
- AI Assist runs only when you invoke it. Nothing is sent otherwise.
- You choose the provider and model. Aarmos does not supply, host, select or fall back to any model.
- When invoked, Aarmos sends the drafting request and a minimised context to that provider and model only.
- Credentials, Evidence and unrelated policy values are not sent.
- The request may be kept with the resulting draft.
- Normal invocation logs keep metadata, not the raw request.
- AI output is an ordinary draft. It needs the same preview, independent review and activation as any other change, and AI Assist cannot preview, review or activate anything itself.
- Aarmos works fully without AI Assist.
Your provider's own terms and privacy policy apply to what it receives. This disclosure describes product behaviour; it adds no privacy commitment beyond it. Read the AI Assist disclosure.
Known limits
Where reliance on Aarmos ends.
- Compromised hosts
- Aarmos does not protect secrets or evidence from a compromised operating system, browser, or same-user process.
- Providers and targets
- Providers and target systems operate under their own controls and terms. Their behavior and downstream results remain outside Aarmos authority.
- Customer governance
- Customers define policy, authority, deployment, credentials, and data classification. Aarmos does not determine whether those choices are sufficient.
- External paths
- Actions that do not reach a supported Aarmos origin are not governed or observed. Unknown path-set completeness remains unknown.
- Effects and outcomes
- Evidence stops at each consequence boundary’s declared ceiling. A valid receipt does not establish an unavailable Effect or business Outcome.
- Certification
- Aarmos can provide evidence relevant to control objectives. It does not certify compliance or make the wider system compliant.
Dependency boundary
A service outage separates local governance from hosted administration.
With required local artifacts available, policy evaluation, receipt signing, local evidence production, and offline verification continue without an Aarmos-hosted service. New sign-ins, account and team administration, entitlement refresh, managed evidence delivery, and hosted views depend on reachable services and may pause or become unavailable.
No uptime claim here
Exact dependency behavior is documented separately. Availability commitments belong in an applicable agreement, not this page.
Review resilience dependencies →Reference owners
Follow the question to its owner.
Shared responsibility →Detailed responsibility allocationSecurity model →Local runtime security architecturePrivacy →Authoritative public data disclosureProve →Verification meaning and ceilingsTrust boundaries →Scoped technical threats, non-goals, and failure behaviorResilience →Dependency and outage behavior