Traceable AI Security
Security for AI agents should not be a black box. Aarmos builds a traceable, tamper-evident record of every governed tool call — what was attempted, what policy said, what you decided, and what actually ran — so your security narrative is backed by evidence, not marketing.
What traceability means
Most agent platforms tell you they are secure. Aarmos gives you the ledger — a chain of signed, inspectable records that an auditor (or your future self) can verify independently.
- Every governed tool call is named and scoped. Before anything runs, you see the exact tool, arguments, and destination. No hidden prompts, no obfuscated payloads.
- Consent decisions become Receipts. Every allow / ask / deny decision is appended to an on-device chain where each Receipt links to the one before it. Tamper an entry and the chain breaks — detection, not prevention, but detection that is cheap to verify.
- Full traces are signed on-device. On Evaluation and above, complete run traces — tool calls, provider handshakes, delegation steps — are signed with this device's Identity. Export as JSONL and verify offline with the portable verifier.
- Audit is the evidence, not an afterthought. The same receipt the operator sees is what the SIEM receives. There is no separate "audit view" that could diverge from reality.
The receipt you can read
Each row is a first-class event in the trace. The signed JSONL export contains the recorded event metadata, signatures, and chain hashes — parseable by standard log analysis tools. Aarmos does not decrypt or inspect request bodies (ADR-0001), so payload contents are only present when an adapter explicitly records them.
Verification, not trust
The signing key stays on the device. Verification uses the corresponding public key, also exportable from the device settings. This means:
- You can prove a trace came from a specific enrolled device.
- You can detect if an exported trace was modified after signing.
- You can reconcile the local ledger with a centralised relay without trusting the relay to hold secrets.
Scope of enforcement — read the fine print
Every guardrail below is enforced by this device's runtime. Compared to server-side gates, that trades tamper- resistance for privacy and offline reach. Be honest with your team about which threat each control is buying down.
- Rate limits & spend ceiling — client-enforced. Excellent against runaway loops, accidents, and typos. A determined insider running a modified build can bypass them. For tamper-resistant caps, also set them at the provider (e.g. OpenAI org limits) and reference them in the ledger.
- Credential redaction — pattern-based on known shapes (
sk-*,Bearer *, JWTs). Reduces accidental leakage into prompts, logs, and receipts; does not replace keeping secrets out of prompts. Add your own regex rules on the Audit page for custom token formats. - Ledger tamper-evidence — the Receipt chain proves no past entry was modified without detection. It does not prove entries were not dropped before signing, or the clock was not rolled. Export an anchor receipt off-device to convert on-device tamper-evidence into a third-party-verifiable pin.
- Browser CSP + on-device vault — hardened script/ style/frame/object sources, AES-GCM vault behind a device password. Does not defend against a malicious browser extension or a compromised OS. See the threat model for the full "does NOT protect against" list.
A traceable record of a bad decision is still a record of a bad decision. Traceability makes agent behaviour auditable; it does not guarantee the behaviour was correct. Governance — per-tool consent, governance policies, and kill switches — is what shapes the behaviour. Read the full honest scope on the threat model.