Security Model and Compliance
This document summarizes Faramesh’s security posture and how it supports compliance and audit. It is aimed at security leads, CISOs, and compliance teams. The normative semantics (fail-closed, default deny, high-risk upgrade, DPR, replay) are defined in the Faramesh Core Specification v1.0 (DOI: 10.5281/zenodo.18371591).
Security guarantees (summary)
Non-bypassable control — Every tool execution passes through the authorization boundary. There is no path that runs an action without a policy decision.
Fail-closed — If the policy engine is unreachable or errors, the default is deny. No “allow when in doubt.”
Deterministic action identity — Actions are canonicalized and hashed so the same action always has the same identity; audit and replay are consistent.
Tamper-evident audit — Decisions are recorded in a hash-chained structure (Merkle chain, DPRs). Cryptographic provenance allows inclusion proofs and replay so you can prove what was decided and why.
No credential storage — The Credential Broker never stores secrets; it uses workload identity (e.g. Vault JWT, AWS STS, Azure federated credential) and ephemeral fetch. Your secrets stay in your vault.
These properties support both operational security (no accidental or malicious bypass) and compliance (audit trail, non-repudiation, replay).
Threat model (high level)
In scope: Unauthorized or unintended agent actions (e.g. dangerous shell commands, over-refunds, data exfiltration). Faramesh is designed to enforce policy at the execution gate and to log every decision.
In scope: Tampering with audit logs. Hash chaining and Merkle proofs make modifications detectable.
Out of scope: Compromise of the agent runtime or host (e.g. if the OS is owned, the plugin can be bypassed). Faramesh assumes the runtime and the gate process are trusted.
Out of scope: Social engineering of humans who approve actions. Faramesh ensures approvals are explicit and logged, not that humans never make bad approval decisions.
For a formal threat model and attack vectors (e.g. in Guard), see the Guard v1 threat-model and related specs.
Compliance and audit
Audit trail — Every decision (allow, deny, require approval) is logged with action identity (hash), policy version, reason code, and timestamp. Export via dashboard or API.
Provenance — Decision Provenance Records (DPR) and Merkle chain provide a cryptographically verifiable record of what was decided and how it chains. Aligns with decision-centric audit (e.g. arXiv:2601.17744).
Replay — You can re-evaluate a historical decision under current (or specified) policy and state via the replay API, supporting “why was this allowed?” and “would we allow it today?”
Retention — Horizon plans define retention for actions and audit data; self-hosted deployments control retention in their own storage.
Use these for internal audits, regulatory evidence, and forensics.
Standards and references
NIST AI RMF / agent considerations — Governance and accountability for AI systems; Faramesh’s human-in-the-loop and audit trail support these.
Workload identity — Credential broker aligns with SPIFFE/SPIRE, Vault JWT, and cloud IAM best practices (no long-lived secrets in the app).
Provenance — Design is aligned with decision-centric, append-only, verifiable provenance (see Cryptographic provenance).
Summary
Faramesh is built so that every action is gated, decisions are deterministic and logged, audit is tamper-evident, and credentials are not stored. That supports both strong operational security and compliance-ready audit and replay. For implementation details, see the authorization boundary, execution gate, CAR, and provenance docs linked above.